1996-07-09 08:22:35 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
1999-02-14 00:22:53 +01:00
|
|
|
* geo_ops.c
|
1996-07-09 08:22:35 +02:00
|
|
|
* 2D geometric operations
|
|
|
|
*
|
2018-11-15 16:08:03 +01:00
|
|
|
* This module implements the geometric functions and operators. The
|
|
|
|
* geometric types are (from simple to more complicated):
|
|
|
|
*
|
|
|
|
* - point
|
|
|
|
* - line
|
|
|
|
* - line segment
|
|
|
|
* - box
|
|
|
|
* - circle
|
|
|
|
* - polygon
|
|
|
|
*
|
2022-01-08 01:04:57 +01:00
|
|
|
* Portions Copyright (c) 1996-2022, PostgreSQL Global Development Group
|
2000-01-26 06:58:53 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/backend/utils/adt/geo_ops.c
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
2002-09-05 02:43:07 +02:00
|
|
|
#include "postgres.h"
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
#include <math.h>
|
1997-07-29 18:08:18 +02:00
|
|
|
#include <limits.h>
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
#include <float.h>
|
|
|
|
#include <ctype.h>
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2003-05-09 23:19:50 +02:00
|
|
|
#include "libpq/pqformat.h"
|
2015-12-14 20:44:40 +01:00
|
|
|
#include "miscadmin.h"
|
2018-07-29 03:30:48 +02:00
|
|
|
#include "utils/float.h"
|
|
|
|
#include "utils/fmgrprotos.h"
|
1997-03-15 00:21:12 +01:00
|
|
|
#include "utils/geo_decls.h"
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2018-11-15 16:08:03 +01:00
|
|
|
/*
|
|
|
|
* * Type constructors have this form:
|
|
|
|
* void type_construct(Type *result, ...);
|
|
|
|
*
|
|
|
|
* * Operators commonly have signatures such as
|
|
|
|
* void type1_operator_type2(Type *result, Type1 *obj1, Type2 *obj2);
|
|
|
|
*
|
|
|
|
* Common operators are:
|
|
|
|
* * Intersection point:
|
|
|
|
* bool type1_interpt_type2(Point *result, Type1 *obj1, Type2 *obj2);
|
|
|
|
* Return whether the two objects intersect. If *result is not NULL,
|
|
|
|
* it is set to the intersection point.
|
|
|
|
*
|
|
|
|
* * Containment:
|
|
|
|
* bool type1_contain_type2(Type1 *obj1, Type2 *obj2);
|
|
|
|
* Return whether obj1 contains obj2.
|
|
|
|
* bool type1_contain_type2(Type1 *contains_obj, Type1 *contained_obj);
|
|
|
|
* Return whether obj1 contains obj2 (used when types are the same)
|
|
|
|
*
|
|
|
|
* * Distance of closest point in or on obj1 to obj2:
|
|
|
|
* float8 type1_closept_type2(Point *result, Type1 *obj1, Type2 *obj2);
|
|
|
|
* Returns the shortest distance between two objects. If *result is not
|
|
|
|
* NULL, it is set to the closest point in or on obj1 to obj2.
|
|
|
|
*
|
|
|
|
* These functions may be used to implement multiple SQL-level operators. For
|
|
|
|
* example, determining whether two lines are parallel is done by checking
|
|
|
|
* whether they don't intersect.
|
|
|
|
*/
|
2002-11-08 19:32:47 +01:00
|
|
|
|
1997-09-20 18:22:31 +02:00
|
|
|
/*
|
|
|
|
* Internal routines
|
|
|
|
*/
|
|
|
|
|
2013-07-09 04:42:39 +02:00
|
|
|
enum path_delim
|
|
|
|
{
|
|
|
|
PATH_NONE, PATH_OPEN, PATH_CLOSED
|
|
|
|
};
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
/* Routines for points */
|
|
|
|
static inline void point_construct(Point *result, float8 x, float8 y);
|
|
|
|
static inline void point_add_point(Point *result, Point *pt1, Point *pt2);
|
|
|
|
static inline void point_sub_point(Point *result, Point *pt1, Point *pt2);
|
|
|
|
static inline void point_mul_point(Point *result, Point *pt1, Point *pt2);
|
|
|
|
static inline void point_div_point(Point *result, Point *pt1, Point *pt2);
|
|
|
|
static inline bool point_eq_point(Point *pt1, Point *pt2);
|
|
|
|
static inline float8 point_dt(Point *pt1, Point *pt2);
|
|
|
|
static inline float8 point_sl(Point *pt1, Point *pt2);
|
1997-08-19 23:40:56 +02:00
|
|
|
static int point_inside(Point *p, int npts, Point *plist);
|
2018-07-29 02:02:48 +02:00
|
|
|
|
|
|
|
/* Routines for lines */
|
|
|
|
static inline void line_construct(LINE *result, Point *pt, float8 m);
|
2018-09-26 10:25:24 +02:00
|
|
|
static inline float8 line_sl(LINE *line);
|
2018-07-29 02:02:48 +02:00
|
|
|
static inline float8 line_invsl(LINE *line);
|
|
|
|
static bool line_interpt_line(Point *result, LINE *l1, LINE *l2);
|
|
|
|
static bool line_contain_point(LINE *line, Point *point);
|
|
|
|
static float8 line_closept_point(Point *result, LINE *line, Point *pt);
|
|
|
|
|
|
|
|
/* Routines for line segments */
|
|
|
|
static inline void statlseg_construct(LSEG *lseg, Point *pt1, Point *pt2);
|
|
|
|
static inline float8 lseg_sl(LSEG *lseg);
|
|
|
|
static inline float8 lseg_invsl(LSEG *lseg);
|
|
|
|
static bool lseg_interpt_line(Point *result, LSEG *lseg, LINE *line);
|
|
|
|
static bool lseg_interpt_lseg(Point *result, LSEG *l1, LSEG *l2);
|
2018-08-16 19:56:11 +02:00
|
|
|
static int lseg_crossing(float8 x, float8 y, float8 px, float8 py);
|
2018-07-29 02:02:48 +02:00
|
|
|
static bool lseg_contain_point(LSEG *lseg, Point *point);
|
|
|
|
static float8 lseg_closept_point(Point *result, LSEG *lseg, Point *pt);
|
|
|
|
static float8 lseg_closept_line(Point *result, LSEG *lseg, LINE *line);
|
2018-11-15 16:08:03 +01:00
|
|
|
static float8 lseg_closept_lseg(Point *result, LSEG *on_lseg, LSEG *to_lseg);
|
2018-07-29 02:02:48 +02:00
|
|
|
|
|
|
|
/* Routines for boxes */
|
|
|
|
static inline void box_construct(BOX *result, Point *pt1, Point *pt2);
|
|
|
|
static void box_cn(Point *center, BOX *box);
|
2000-07-30 22:44:02 +02:00
|
|
|
static bool box_ov(BOX *box1, BOX *box2);
|
2018-08-16 19:56:11 +02:00
|
|
|
static float8 box_ar(BOX *box);
|
|
|
|
static float8 box_ht(BOX *box);
|
|
|
|
static float8 box_wd(BOX *box);
|
2018-07-29 02:02:48 +02:00
|
|
|
static bool box_contain_point(BOX *box, Point *point);
|
2018-11-15 16:08:03 +01:00
|
|
|
static bool box_contain_box(BOX *contains_box, BOX *contained_box);
|
2018-07-29 02:02:48 +02:00
|
|
|
static bool box_contain_lseg(BOX *box, LSEG *lseg);
|
|
|
|
static bool box_interpt_lseg(Point *result, BOX *box, LSEG *lseg);
|
|
|
|
static float8 box_closept_point(Point *result, BOX *box, Point *point);
|
|
|
|
static float8 box_closept_lseg(Point *result, BOX *box, LSEG *lseg);
|
|
|
|
|
|
|
|
/* Routines for circles */
|
2018-08-16 19:56:11 +02:00
|
|
|
static float8 circle_ar(CIRCLE *circle);
|
2018-07-29 02:02:48 +02:00
|
|
|
|
|
|
|
/* Routines for polygons */
|
1997-08-19 23:40:56 +02:00
|
|
|
static void make_bound_box(POLYGON *poly);
|
2018-07-29 02:02:48 +02:00
|
|
|
static void poly_to_circle(CIRCLE *result, POLYGON *poly);
|
|
|
|
static bool lseg_inside_poly(Point *a, Point *b, POLYGON *poly, int start);
|
2018-11-15 16:08:03 +01:00
|
|
|
static bool poly_contain_poly(POLYGON *contains_poly, POLYGON *contained_poly);
|
1997-08-19 23:40:56 +02:00
|
|
|
static bool plist_same(int npts, Point *p1, Point *p2);
|
2018-07-29 02:02:48 +02:00
|
|
|
static float8 dist_ppoly_internal(Point *pt, POLYGON *poly);
|
|
|
|
|
|
|
|
/* Routines for encoding and decoding */
|
2018-08-16 19:56:11 +02:00
|
|
|
static float8 single_decode(char *num, char **endptr_p,
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
const char *type_name, const char *orig_string);
|
|
|
|
static void single_encode(float8 x, StringInfo str);
|
2018-08-16 19:56:11 +02:00
|
|
|
static void pair_decode(char *str, float8 *x, float8 *y, char **endptr_p,
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
const char *type_name, const char *orig_string);
|
|
|
|
static void pair_encode(float8 x, float8 y, StringInfo str);
|
1997-08-19 23:40:56 +02:00
|
|
|
static int pair_count(char *s, char delim);
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
static void path_decode(char *str, bool opentype, int npts, Point *p,
|
|
|
|
bool *isopen, char **endptr_p,
|
|
|
|
const char *type_name, const char *orig_string);
|
2013-07-09 04:42:39 +02:00
|
|
|
static char *path_encode(enum path_delim path_delim, int npts, Point *pt);
|
1997-08-19 23:40:56 +02:00
|
|
|
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Delimiters for input and output strings.
|
|
|
|
* LDELIM, RDELIM, and DELIM are left, right, and separator delimiters, respectively.
|
|
|
|
* LDELIM_EP, RDELIM_EP are left and right delimiters for paths with endpoints.
|
|
|
|
*/
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
#define LDELIM '('
|
|
|
|
#define RDELIM ')'
|
|
|
|
#define DELIM ','
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
#define LDELIM_EP '['
|
|
|
|
#define RDELIM_EP ']'
|
|
|
|
#define LDELIM_C '<'
|
|
|
|
#define RDELIM_C '>'
|
2018-07-29 02:02:48 +02:00
|
|
|
#define LDELIM_L '{'
|
|
|
|
#define RDELIM_L '}'
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Geometric data types are composed of points.
|
|
|
|
* This code tries to support a common format throughout the data types,
|
|
|
|
* to allow for more predictable usage and data type conversion.
|
|
|
|
* The fundamental unit is the point. Other units are line segments,
|
|
|
|
* open paths, boxes, closed paths, and polygons (which should be considered
|
|
|
|
* non-intersecting closed paths).
|
|
|
|
*
|
|
|
|
* Data representation is as follows:
|
|
|
|
* point: (x,y)
|
|
|
|
* line segment: [(x1,y1),(x2,y2)]
|
|
|
|
* box: (x1,y1),(x2,y2)
|
|
|
|
* open path: [(x1,y1),...,(xn,yn)]
|
|
|
|
* closed path: ((x1,y1),...,(xn,yn))
|
|
|
|
* polygon: ((x1,y1),...,(xn,yn))
|
|
|
|
*
|
|
|
|
* For boxes, the points are opposite corners with the first point at the top right.
|
|
|
|
* For closed paths and polygons, the points should be reordered to allow
|
|
|
|
* fast and correct equality comparisons.
|
|
|
|
*
|
|
|
|
* XXX perhaps points in complex shapes should be reordered internally
|
|
|
|
* to allow faster internal operations, but should keep track of input order
|
|
|
|
* and restore that order for text output - tgl 97/01/16
|
|
|
|
*/
|
|
|
|
|
2018-08-16 19:56:11 +02:00
|
|
|
static float8
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
single_decode(char *num, char **endptr_p,
|
|
|
|
const char *type_name, const char *orig_string)
|
1997-07-29 18:08:18 +02:00
|
|
|
{
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
return float8in_internal(num, endptr_p, type_name, orig_string);
|
1998-02-03 16:55:58 +01:00
|
|
|
} /* single_decode() */
|
1997-07-29 18:08:18 +02:00
|
|
|
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
static void
|
|
|
|
single_encode(float8 x, StringInfo str)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
char *xstr = float8out_internal(x);
|
2002-11-08 18:37:52 +01:00
|
|
|
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
appendStringInfoString(str, xstr);
|
|
|
|
pfree(xstr);
|
1998-02-03 16:55:58 +01:00
|
|
|
} /* single_encode() */
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
static void
|
2018-08-16 19:56:11 +02:00
|
|
|
pair_decode(char *str, float8 *x, float8 *y, char **endptr_p,
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
const char *type_name, const char *orig_string)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
bool has_delim;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-12-03 21:45:40 +01:00
|
|
|
while (isspace((unsigned char) *str))
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
str++;
|
|
|
|
if ((has_delim = (*str == LDELIM)))
|
|
|
|
str++;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
*x = float8in_internal(str, &str, type_name, orig_string);
|
|
|
|
|
|
|
|
if (*str++ != DELIM)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
|
|
|
|
errmsg("invalid input syntax for type %s: \"%s\"",
|
|
|
|
type_name, orig_string)));
|
|
|
|
|
|
|
|
*y = float8in_internal(str, &str, type_name, orig_string);
|
|
|
|
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
if (has_delim)
|
|
|
|
{
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
if (*str++ != RDELIM)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
|
|
|
|
errmsg("invalid input syntax for type %s: \"%s\"",
|
|
|
|
type_name, orig_string)));
|
2000-12-03 21:45:40 +01:00
|
|
|
while (isspace((unsigned char) *str))
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
str++;
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
/* report stopping point if wanted, else complain if not end of string */
|
|
|
|
if (endptr_p)
|
|
|
|
*endptr_p = str;
|
|
|
|
else if (*str != '\0')
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
|
|
|
|
errmsg("invalid input syntax for type %s: \"%s\"",
|
|
|
|
type_name, orig_string)));
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
}
|
|
|
|
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
static void
|
|
|
|
pair_encode(float8 x, float8 y, StringInfo str)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
char *xstr = float8out_internal(x);
|
|
|
|
char *ystr = float8out_internal(y);
|
2002-11-08 18:37:52 +01:00
|
|
|
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
appendStringInfo(str, "%s,%s", xstr, ystr);
|
|
|
|
pfree(xstr);
|
|
|
|
pfree(ystr);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
}
|
|
|
|
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
static void
|
|
|
|
path_decode(char *str, bool opentype, int npts, Point *p,
|
|
|
|
bool *isopen, char **endptr_p,
|
|
|
|
const char *type_name, const char *orig_string)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
|
|
|
int depth = 0;
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
char *cp;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
int i;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
while (isspace((unsigned char) *str))
|
|
|
|
str++;
|
|
|
|
if ((*isopen = (*str == LDELIM_EP)))
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
|
|
|
/* no open delimiter allowed? */
|
|
|
|
if (!opentype)
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
|
|
|
|
errmsg("invalid input syntax for type %s: \"%s\"",
|
|
|
|
type_name, orig_string)));
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
depth++;
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
str++;
|
1997-09-05 20:13:45 +02:00
|
|
|
}
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
else if (*str == LDELIM)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
cp = (str + 1);
|
2000-12-03 21:45:40 +01:00
|
|
|
while (isspace((unsigned char) *cp))
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
cp++;
|
|
|
|
if (*cp == LDELIM)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
|
|
|
depth++;
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
str = cp;
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
else if (strrchr(str, LDELIM) == str)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
|
|
|
depth++;
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
str = cp;
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
|
|
|
for (i = 0; i < npts; i++)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
pair_decode(str, &(p->x), &(p->y), &str, type_name, orig_string);
|
|
|
|
if (*str == DELIM)
|
|
|
|
str++;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
p++;
|
1997-09-05 20:13:45 +02:00
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
|
|
|
while (depth > 0)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2018-07-29 02:02:48 +02:00
|
|
|
if (*str == RDELIM || (*str == RDELIM_EP && *isopen && depth == 1))
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
|
|
|
depth--;
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
str++;
|
|
|
|
while (isspace((unsigned char) *str))
|
|
|
|
str++;
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
else
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
|
|
|
|
errmsg("invalid input syntax for type %s: \"%s\"",
|
|
|
|
type_name, orig_string)));
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
/* report stopping point if wanted, else complain if not end of string */
|
|
|
|
if (endptr_p)
|
|
|
|
*endptr_p = str;
|
|
|
|
else if (*str != '\0')
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
|
|
|
|
errmsg("invalid input syntax for type %s: \"%s\"",
|
|
|
|
type_name, orig_string)));
|
1998-02-03 16:55:58 +01:00
|
|
|
} /* path_decode() */
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1997-08-19 23:40:56 +02:00
|
|
|
static char *
|
2013-07-09 04:42:39 +02:00
|
|
|
path_encode(enum path_delim path_delim, int npts, Point *pt)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
StringInfoData str;
|
1997-09-07 07:04:48 +02:00
|
|
|
int i;
|
|
|
|
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
initStringInfo(&str);
|
2002-08-30 01:05:44 +02:00
|
|
|
|
2013-07-09 04:42:39 +02:00
|
|
|
switch (path_delim)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2013-07-09 04:42:39 +02:00
|
|
|
case PATH_CLOSED:
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
appendStringInfoChar(&str, LDELIM);
|
1997-09-07 07:04:48 +02:00
|
|
|
break;
|
2013-07-09 04:42:39 +02:00
|
|
|
case PATH_OPEN:
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
appendStringInfoChar(&str, LDELIM_EP);
|
1997-09-07 07:04:48 +02:00
|
|
|
break;
|
2013-07-09 04:42:39 +02:00
|
|
|
case PATH_NONE:
|
1997-09-07 07:04:48 +02:00
|
|
|
break;
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-08-19 23:40:56 +02:00
|
|
|
for (i = 0; i < npts; i++)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
if (i > 0)
|
|
|
|
appendStringInfoChar(&str, DELIM);
|
|
|
|
appendStringInfoChar(&str, LDELIM);
|
|
|
|
pair_encode(pt->x, pt->y, &str);
|
|
|
|
appendStringInfoChar(&str, RDELIM);
|
1997-05-06 09:27:51 +02:00
|
|
|
pt++;
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
|
2013-07-09 04:42:39 +02:00
|
|
|
switch (path_delim)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2013-07-09 04:42:39 +02:00
|
|
|
case PATH_CLOSED:
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
appendStringInfoChar(&str, RDELIM);
|
1997-05-06 09:27:51 +02:00
|
|
|
break;
|
2013-07-09 04:42:39 +02:00
|
|
|
case PATH_OPEN:
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
appendStringInfoChar(&str, RDELIM_EP);
|
1997-09-07 07:04:48 +02:00
|
|
|
break;
|
2013-07-09 04:42:39 +02:00
|
|
|
case PATH_NONE:
|
1997-09-07 07:04:48 +02:00
|
|
|
break;
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
return str.data;
|
1998-02-03 16:55:58 +01:00
|
|
|
} /* path_encode() */
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
|
|
|
/*-------------------------------------------------------------
|
|
|
|
* pair_count - count the number of points
|
|
|
|
* allow the following notation:
|
|
|
|
* '((1,2),(3,4))'
|
|
|
|
* '(1,3,2,4)'
|
|
|
|
* require an odd number of delim characters in the string
|
|
|
|
*-------------------------------------------------------------*/
|
1997-08-19 23:40:56 +02:00
|
|
|
static int
|
|
|
|
pair_count(char *s, char delim)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
|
|
|
int ndelim = 0;
|
|
|
|
|
|
|
|
while ((s = strchr(s, delim)) != NULL)
|
|
|
|
{
|
|
|
|
ndelim++;
|
|
|
|
s++;
|
1997-09-05 20:13:45 +02:00
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
return (ndelim % 2) ? ((ndelim + 1) / 2) : -1;
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/***********************************************************************
|
|
|
|
**
|
|
|
|
** Routines for two-dimensional boxes.
|
|
|
|
**
|
|
|
|
***********************************************************************/
|
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
|
|
|
* Formatting and conversion routines.
|
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
|
|
|
/* box_in - convert a string to internal form.
|
|
|
|
*
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
* External format: (two corners of box)
|
|
|
|
* "(f8, f8), (f8, f8)"
|
|
|
|
* also supports the older style "(f8, f8, f8, f8)"
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_in(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
char *str = PG_GETARG_CSTRING(0);
|
|
|
|
BOX *box = (BOX *) palloc(sizeof(BOX));
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
bool isopen;
|
2018-08-16 19:56:11 +02:00
|
|
|
float8 x,
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
y;
|
|
|
|
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
path_decode(str, false, 2, &(box->high), &isopen, NULL, "box", str);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
|
|
|
/* reorder corners if necessary... */
|
2018-08-16 19:56:11 +02:00
|
|
|
if (float8_lt(box->high.x, box->low.x))
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
|
|
|
x = box->high.x;
|
|
|
|
box->high.x = box->low.x;
|
|
|
|
box->low.x = x;
|
1997-09-05 20:13:45 +02:00
|
|
|
}
|
2018-08-16 19:56:11 +02:00
|
|
|
if (float8_lt(box->high.y, box->low.y))
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
|
|
|
y = box->high.y;
|
|
|
|
box->high.y = box->low.y;
|
|
|
|
box->low.y = y;
|
1997-09-05 20:13:45 +02:00
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOX_P(box);
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
/* box_out - convert a box to external form.
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_out(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box = PG_GETARG_BOX_P(0);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2013-07-09 04:42:39 +02:00
|
|
|
PG_RETURN_CSTRING(path_encode(PATH_NONE, 2, &(box->high)));
|
2000-07-30 22:44:02 +02:00
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2003-05-13 20:03:08 +02:00
|
|
|
/*
|
|
|
|
* box_recv - converts external binary format to box
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
box_recv(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
StringInfo buf = (StringInfo) PG_GETARG_POINTER(0);
|
|
|
|
BOX *box;
|
2018-08-16 19:56:11 +02:00
|
|
|
float8 x,
|
2003-05-13 20:03:08 +02:00
|
|
|
y;
|
|
|
|
|
|
|
|
box = (BOX *) palloc(sizeof(BOX));
|
|
|
|
|
|
|
|
box->high.x = pq_getmsgfloat8(buf);
|
|
|
|
box->high.y = pq_getmsgfloat8(buf);
|
|
|
|
box->low.x = pq_getmsgfloat8(buf);
|
|
|
|
box->low.y = pq_getmsgfloat8(buf);
|
|
|
|
|
|
|
|
/* reorder corners if necessary... */
|
2018-08-16 19:56:11 +02:00
|
|
|
if (float8_lt(box->high.x, box->low.x))
|
2003-05-13 20:03:08 +02:00
|
|
|
{
|
|
|
|
x = box->high.x;
|
|
|
|
box->high.x = box->low.x;
|
|
|
|
box->low.x = x;
|
|
|
|
}
|
2018-08-16 19:56:11 +02:00
|
|
|
if (float8_lt(box->high.y, box->low.y))
|
2003-05-13 20:03:08 +02:00
|
|
|
{
|
|
|
|
y = box->high.y;
|
|
|
|
box->high.y = box->low.y;
|
|
|
|
box->low.y = y;
|
|
|
|
}
|
|
|
|
|
|
|
|
PG_RETURN_BOX_P(box);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* box_send - converts box to binary format
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
box_send(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
BOX *box = PG_GETARG_BOX_P(0);
|
|
|
|
StringInfoData buf;
|
|
|
|
|
|
|
|
pq_begintypsend(&buf);
|
|
|
|
pq_sendfloat8(&buf, box->high.x);
|
|
|
|
pq_sendfloat8(&buf, box->high.y);
|
|
|
|
pq_sendfloat8(&buf, box->low.x);
|
|
|
|
pq_sendfloat8(&buf, box->low.y);
|
|
|
|
PG_RETURN_BYTEA_P(pq_endtypsend(&buf));
|
|
|
|
}
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
/* box_construct - fill in a new box.
|
|
|
|
*/
|
2018-07-29 02:02:48 +02:00
|
|
|
static inline void
|
|
|
|
box_construct(BOX *result, Point *pt1, Point *pt2)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2018-08-16 19:56:11 +02:00
|
|
|
if (float8_gt(pt1->x, pt2->x))
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2018-07-29 02:02:48 +02:00
|
|
|
result->high.x = pt1->x;
|
|
|
|
result->low.x = pt2->x;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2018-07-29 02:02:48 +02:00
|
|
|
result->high.x = pt2->x;
|
|
|
|
result->low.x = pt1->x;
|
1997-09-05 20:13:45 +02:00
|
|
|
}
|
2018-08-16 19:56:11 +02:00
|
|
|
if (float8_gt(pt1->y, pt2->y))
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2018-07-29 02:02:48 +02:00
|
|
|
result->high.y = pt1->y;
|
|
|
|
result->low.y = pt2->y;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2018-07-29 02:02:48 +02:00
|
|
|
result->high.y = pt2->y;
|
|
|
|
result->low.y = pt1->y;
|
1997-09-05 20:13:45 +02:00
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
|
|
|
* Relational operators for BOXes.
|
|
|
|
* <, >, <=, >=, and == are based on box area.
|
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
|
|
|
/* box_same - are two boxes identical?
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_same(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box1 = PG_GETARG_BOX_P(0);
|
|
|
|
BOX *box2 = PG_GETARG_BOX_P(1);
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
PG_RETURN_BOOL(point_eq_point(&box1->high, &box2->high) &&
|
|
|
|
point_eq_point(&box1->low, &box2->low));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* box_overlap - does box1 overlap box2?
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_overlap(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box1 = PG_GETARG_BOX_P(0);
|
|
|
|
BOX *box2 = PG_GETARG_BOX_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(box_ov(box1, box2));
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool
|
|
|
|
box_ov(BOX *box1, BOX *box2)
|
|
|
|
{
|
2013-02-09 00:26:08 +01:00
|
|
|
return (FPle(box1->low.x, box2->high.x) &&
|
|
|
|
FPle(box2->low.x, box1->high.x) &&
|
|
|
|
FPle(box1->low.y, box2->high.y) &&
|
|
|
|
FPle(box2->low.y, box1->high.y));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2005-06-24 22:53:34 +02:00
|
|
|
/* box_left - is box1 strictly left of box2?
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
2005-06-24 22:53:34 +02:00
|
|
|
box_left(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box1 = PG_GETARG_BOX_P(0);
|
|
|
|
BOX *box2 = PG_GETARG_BOX_P(1);
|
|
|
|
|
2005-06-24 22:53:34 +02:00
|
|
|
PG_RETURN_BOOL(FPlt(box1->high.x, box2->low.x));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2005-06-24 22:53:34 +02:00
|
|
|
/* box_overleft - is the right edge of box1 at or left of
|
|
|
|
* the right edge of box2?
|
|
|
|
*
|
|
|
|
* This is "less than or equal" for the end of a time range,
|
|
|
|
* when time ranges are stored as rectangles.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
2005-06-24 22:53:34 +02:00
|
|
|
box_overleft(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box1 = PG_GETARG_BOX_P(0);
|
|
|
|
BOX *box2 = PG_GETARG_BOX_P(1);
|
|
|
|
|
2005-06-24 22:53:34 +02:00
|
|
|
PG_RETURN_BOOL(FPle(box1->high.x, box2->high.x));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* box_right - is box1 strictly right of box2?
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_right(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box1 = PG_GETARG_BOX_P(0);
|
|
|
|
BOX *box2 = PG_GETARG_BOX_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPgt(box1->low.x, box2->high.x));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2005-06-24 22:53:34 +02:00
|
|
|
/* box_overright - is the left edge of box1 at or right of
|
1996-07-09 08:22:35 +02:00
|
|
|
* the left edge of box2?
|
|
|
|
*
|
|
|
|
* This is "greater than or equal" for time ranges, when time ranges
|
|
|
|
* are stored as rectangles.
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_overright(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box1 = PG_GETARG_BOX_P(0);
|
|
|
|
BOX *box2 = PG_GETARG_BOX_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPge(box1->low.x, box2->low.x));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2005-06-24 22:53:34 +02:00
|
|
|
/* box_below - is box1 strictly below box2?
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
box_below(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
BOX *box1 = PG_GETARG_BOX_P(0);
|
|
|
|
BOX *box2 = PG_GETARG_BOX_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPlt(box1->high.y, box2->low.y));
|
|
|
|
}
|
|
|
|
|
|
|
|
/* box_overbelow - is the upper edge of box1 at or below
|
|
|
|
* the upper edge of box2?
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
box_overbelow(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
BOX *box1 = PG_GETARG_BOX_P(0);
|
|
|
|
BOX *box2 = PG_GETARG_BOX_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPle(box1->high.y, box2->high.y));
|
|
|
|
}
|
|
|
|
|
|
|
|
/* box_above - is box1 strictly above box2?
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
box_above(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
BOX *box1 = PG_GETARG_BOX_P(0);
|
|
|
|
BOX *box2 = PG_GETARG_BOX_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPgt(box1->low.y, box2->high.y));
|
|
|
|
}
|
|
|
|
|
|
|
|
/* box_overabove - is the lower edge of box1 at or above
|
|
|
|
* the lower edge of box2?
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
box_overabove(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
BOX *box1 = PG_GETARG_BOX_P(0);
|
|
|
|
BOX *box2 = PG_GETARG_BOX_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPge(box1->low.y, box2->low.y));
|
|
|
|
}
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/* box_contained - is box1 contained by box2?
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_contained(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box1 = PG_GETARG_BOX_P(0);
|
|
|
|
BOX *box2 = PG_GETARG_BOX_P(1);
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
PG_RETURN_BOOL(box_contain_box(box2, box1));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* box_contain - does box1 contain box2?
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_contain(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box1 = PG_GETARG_BOX_P(0);
|
|
|
|
BOX *box2 = PG_GETARG_BOX_P(1);
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
PG_RETURN_BOOL(box_contain_box(box1, box2));
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2018-11-15 16:08:03 +01:00
|
|
|
* Check whether the second box is in the first box or on its border
|
2018-07-29 02:02:48 +02:00
|
|
|
*/
|
|
|
|
static bool
|
2018-11-15 16:08:03 +01:00
|
|
|
box_contain_box(BOX *contains_box, BOX *contained_box)
|
2018-07-29 02:02:48 +02:00
|
|
|
{
|
2018-11-15 16:08:03 +01:00
|
|
|
return FPge(contains_box->high.x, contained_box->high.x) &&
|
|
|
|
FPle(contains_box->low.x, contained_box->low.x) &&
|
|
|
|
FPge(contains_box->high.y, contained_box->high.y) &&
|
|
|
|
FPle(contains_box->low.y, contained_box->low.y);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* box_positionop -
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
* is box1 entirely {above,below} box2?
|
2005-06-24 22:53:34 +02:00
|
|
|
*
|
|
|
|
* box_below_eq and box_above_eq are obsolete versions that (probably
|
|
|
|
* erroneously) accept the equal-boundaries case. Since these are not
|
|
|
|
* in sync with the box_left and box_right code, they are deprecated and
|
|
|
|
* not supported in the PG 8.1 rtree operator class extension.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
2005-06-24 22:53:34 +02:00
|
|
|
box_below_eq(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box1 = PG_GETARG_BOX_P(0);
|
|
|
|
BOX *box2 = PG_GETARG_BOX_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPle(box1->high.y, box2->low.y));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
2005-06-24 22:53:34 +02:00
|
|
|
box_above_eq(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box1 = PG_GETARG_BOX_P(0);
|
|
|
|
BOX *box2 = PG_GETARG_BOX_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPge(box1->low.y, box2->high.y));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* box_relop - is area(box1) relop area(box2), within
|
|
|
|
* our accuracy constraint?
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_lt(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box1 = PG_GETARG_BOX_P(0);
|
|
|
|
BOX *box2 = PG_GETARG_BOX_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPlt(box_ar(box1), box_ar(box2)));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_gt(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box1 = PG_GETARG_BOX_P(0);
|
|
|
|
BOX *box2 = PG_GETARG_BOX_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPgt(box_ar(box1), box_ar(box2)));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_eq(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box1 = PG_GETARG_BOX_P(0);
|
|
|
|
BOX *box2 = PG_GETARG_BOX_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPeq(box_ar(box1), box_ar(box2)));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_le(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box1 = PG_GETARG_BOX_P(0);
|
|
|
|
BOX *box2 = PG_GETARG_BOX_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPle(box_ar(box1), box_ar(box2)));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_ge(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box1 = PG_GETARG_BOX_P(0);
|
|
|
|
BOX *box2 = PG_GETARG_BOX_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPge(box_ar(box1), box_ar(box2)));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
|
|
|
* "Arithmetic" operators on boxes.
|
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
|
|
|
/* box_area - returns the area of the box.
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_area(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box = PG_GETARG_BOX_P(0);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_FLOAT8(box_ar(box));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
1997-07-29 18:08:18 +02:00
|
|
|
/* box_width - returns the width of the box
|
1996-07-09 08:22:35 +02:00
|
|
|
* (horizontal magnitude).
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_width(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box = PG_GETARG_BOX_P(0);
|
1997-05-06 09:27:51 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
PG_RETURN_FLOAT8(box_wd(box));
|
2000-07-30 22:44:02 +02:00
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
/* box_height - returns the height of the box
|
|
|
|
* (vertical magnitude).
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_height(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box = PG_GETARG_BOX_P(0);
|
1997-05-06 09:27:51 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
PG_RETURN_FLOAT8(box_ht(box));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* box_distance - returns the distance between the
|
|
|
|
* center points of two boxes.
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_distance(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box1 = PG_GETARG_BOX_P(0);
|
|
|
|
BOX *box2 = PG_GETARG_BOX_P(1);
|
|
|
|
Point a,
|
|
|
|
b;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
box_cn(&a, box1);
|
|
|
|
box_cn(&b, box2);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
PG_RETURN_FLOAT8(point_dt(&a, &b));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* box_center - returns the center point of the box.
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_center(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box = PG_GETARG_BOX_P(0);
|
|
|
|
Point *result = (Point *) palloc(sizeof(Point));
|
1997-05-06 09:27:51 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
box_cn(result, box);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_POINT_P(result);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* box_ar - returns the area of the box.
|
|
|
|
*/
|
2018-08-16 19:56:11 +02:00
|
|
|
static float8
|
1997-08-19 23:40:56 +02:00
|
|
|
box_ar(BOX *box)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2018-08-16 19:56:11 +02:00
|
|
|
return float8_mul(box_wd(box), box_ht(box));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
/* box_cn - stores the centerpoint of the box into *center.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
box_cn(Point *center, BOX *box)
|
|
|
|
{
|
2018-08-16 19:56:11 +02:00
|
|
|
center->x = float8_div(float8_pl(box->high.x, box->low.x), 2.0);
|
|
|
|
center->y = float8_div(float8_pl(box->high.y, box->low.y), 2.0);
|
2000-07-30 22:44:02 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
1997-07-29 18:08:18 +02:00
|
|
|
/* box_wd - returns the width (length) of the box
|
1996-07-09 08:22:35 +02:00
|
|
|
* (horizontal magnitude).
|
|
|
|
*/
|
2018-08-16 19:56:11 +02:00
|
|
|
static float8
|
1997-08-19 23:40:56 +02:00
|
|
|
box_wd(BOX *box)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2018-08-16 19:56:11 +02:00
|
|
|
return float8_mi(box->high.x, box->low.x);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* box_ht - returns the height of the box
|
|
|
|
* (vertical magnitude).
|
|
|
|
*/
|
2018-08-16 19:56:11 +02:00
|
|
|
static float8
|
1997-08-19 23:40:56 +02:00
|
|
|
box_ht(BOX *box)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2018-08-16 19:56:11 +02:00
|
|
|
return float8_mi(box->high.y, box->low.y);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
|
|
|
* Funky operations.
|
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
|
|
|
/* box_intersect -
|
|
|
|
* returns the overlapping portion of two boxes,
|
|
|
|
* or NULL if they do not intersect.
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_intersect(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box1 = PG_GETARG_BOX_P(0);
|
|
|
|
BOX *box2 = PG_GETARG_BOX_P(1);
|
1996-07-09 08:22:35 +02:00
|
|
|
BOX *result;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
if (!box_ov(box1, box2))
|
|
|
|
PG_RETURN_NULL();
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
result = (BOX *) palloc(sizeof(BOX));
|
1997-05-06 09:27:51 +02:00
|
|
|
|
2018-08-16 19:56:11 +02:00
|
|
|
result->high.x = float8_min(box1->high.x, box2->high.x);
|
|
|
|
result->low.x = float8_max(box1->low.x, box2->low.x);
|
|
|
|
result->high.y = float8_min(box1->high.y, box2->high.y);
|
|
|
|
result->low.y = float8_max(box1->low.y, box2->low.y);
|
1997-05-06 09:27:51 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOX_P(result);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* box_diagonal -
|
|
|
|
* returns a line segment which happens to be the
|
|
|
|
* positive-slope diagonal of "box".
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_diagonal(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box = PG_GETARG_BOX_P(0);
|
|
|
|
LSEG *result = (LSEG *) palloc(sizeof(LSEG));
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
statlseg_construct(result, &box->high, &box->low);
|
|
|
|
|
|
|
|
PG_RETURN_LSEG_P(result);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/***********************************************************************
|
|
|
|
**
|
|
|
|
** Routines for 2D lines.
|
|
|
|
**
|
|
|
|
***********************************************************************/
|
|
|
|
|
2013-10-09 07:09:18 +02:00
|
|
|
static bool
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
line_decode(char *s, const char *str, LINE *line)
|
2013-10-09 07:09:18 +02:00
|
|
|
{
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
/* s was already advanced over leading '{' */
|
|
|
|
line->A = single_decode(s, &s, "line", str);
|
|
|
|
if (*s++ != DELIM)
|
2013-10-09 07:09:18 +02:00
|
|
|
return false;
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
line->B = single_decode(s, &s, "line", str);
|
|
|
|
if (*s++ != DELIM)
|
2013-10-09 07:09:18 +02:00
|
|
|
return false;
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
line->C = single_decode(s, &s, "line", str);
|
2018-07-29 02:02:48 +02:00
|
|
|
if (*s++ != RDELIM_L)
|
2013-10-09 07:09:18 +02:00
|
|
|
return false;
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
while (isspace((unsigned char) *s))
|
|
|
|
s++;
|
|
|
|
if (*s != '\0')
|
2013-10-09 07:09:18 +02:00
|
|
|
return false;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
line_in(PG_FUNCTION_ARGS)
|
1998-05-10 00:39:55 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
char *str = PG_GETARG_CSTRING(0);
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
LINE *line = (LINE *) palloc(sizeof(LINE));
|
1998-05-10 00:39:55 +02:00
|
|
|
LSEG lseg;
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
bool isopen;
|
1998-05-10 00:39:55 +02:00
|
|
|
char *s;
|
1998-09-01 06:40:42 +02:00
|
|
|
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
s = str;
|
|
|
|
while (isspace((unsigned char) *s))
|
|
|
|
s++;
|
2018-07-29 02:02:48 +02:00
|
|
|
if (*s == LDELIM_L)
|
2013-10-09 07:09:18 +02:00
|
|
|
{
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
if (!line_decode(s + 1, str, line))
|
2013-10-09 07:09:18 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
errmsg("invalid input syntax for type %s: \"%s\"",
|
|
|
|
"line", str)));
|
2013-10-09 07:09:18 +02:00
|
|
|
if (FPzero(line->A) && FPzero(line->B))
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
|
|
|
|
errmsg("invalid line specification: A and B cannot both be zero")));
|
|
|
|
}
|
|
|
|
else
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
{
|
2018-07-29 02:02:48 +02:00
|
|
|
path_decode(s, true, 2, &lseg.p[0], &isopen, NULL, "line", str);
|
|
|
|
if (point_eq_point(&lseg.p[0], &lseg.p[1]))
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
|
|
|
|
errmsg("invalid line specification: must be two distinct points")));
|
2018-07-29 02:02:48 +02:00
|
|
|
line_construct(line, &lseg.p[0], lseg_sl(&lseg));
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
}
|
1998-05-10 00:39:55 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_LINE_P(line);
|
|
|
|
}
|
1998-05-10 00:39:55 +02:00
|
|
|
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
line_out(PG_FUNCTION_ARGS)
|
1998-05-10 00:39:55 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LINE *line = PG_GETARG_LINE_P(0);
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
char *astr = float8out_internal(line->A);
|
|
|
|
char *bstr = float8out_internal(line->B);
|
|
|
|
char *cstr = float8out_internal(line->C);
|
1998-05-10 00:39:55 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
PG_RETURN_CSTRING(psprintf("%c%s%c%s%c%s%c", LDELIM_L, astr, DELIM, bstr,
|
|
|
|
DELIM, cstr, RDELIM_L));
|
2000-07-30 22:44:02 +02:00
|
|
|
}
|
1998-05-10 00:39:55 +02:00
|
|
|
|
2003-05-13 20:03:08 +02:00
|
|
|
/*
|
|
|
|
* line_recv - converts external binary format to line
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
line_recv(PG_FUNCTION_ARGS)
|
|
|
|
{
|
2013-10-09 07:09:18 +02:00
|
|
|
StringInfo buf = (StringInfo) PG_GETARG_POINTER(0);
|
|
|
|
LINE *line;
|
|
|
|
|
|
|
|
line = (LINE *) palloc(sizeof(LINE));
|
|
|
|
|
|
|
|
line->A = pq_getmsgfloat8(buf);
|
|
|
|
line->B = pq_getmsgfloat8(buf);
|
|
|
|
line->C = pq_getmsgfloat8(buf);
|
|
|
|
|
2018-09-26 10:25:24 +02:00
|
|
|
if (FPzero(line->A) && FPzero(line->B))
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_BINARY_REPRESENTATION),
|
|
|
|
errmsg("invalid line specification: A and B cannot both be zero")));
|
|
|
|
|
2013-10-09 07:09:18 +02:00
|
|
|
PG_RETURN_LINE_P(line);
|
2003-05-13 20:03:08 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* line_send - converts line to binary format
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
line_send(PG_FUNCTION_ARGS)
|
|
|
|
{
|
2013-10-09 07:09:18 +02:00
|
|
|
LINE *line = PG_GETARG_LINE_P(0);
|
|
|
|
StringInfoData buf;
|
|
|
|
|
|
|
|
pq_begintypsend(&buf);
|
|
|
|
pq_sendfloat8(&buf, line->A);
|
|
|
|
pq_sendfloat8(&buf, line->B);
|
|
|
|
pq_sendfloat8(&buf, line->C);
|
|
|
|
PG_RETURN_BYTEA_P(pq_endtypsend(&buf));
|
2003-05-13 20:03:08 +02:00
|
|
|
}
|
|
|
|
|
1998-05-10 00:39:55 +02:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*----------------------------------------------------------
|
|
|
|
* Conversion routines from one line formula to internal.
|
|
|
|
* Internal form: Ax+By+C=0
|
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
/*
|
|
|
|
* Fill already-allocated LINE struct from the point and the slope
|
1998-05-10 00:39:55 +02:00
|
|
|
*/
|
2018-07-29 02:02:48 +02:00
|
|
|
static inline void
|
|
|
|
line_construct(LINE *result, Point *pt, float8 m)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2020-11-21 23:24:07 +01:00
|
|
|
if (isinf(m))
|
2010-11-10 22:51:39 +01:00
|
|
|
{
|
|
|
|
/* vertical - use "x = C" */
|
2018-08-16 19:56:11 +02:00
|
|
|
result->A = -1.0;
|
|
|
|
result->B = 0.0;
|
2010-11-10 22:51:39 +01:00
|
|
|
result->C = pt->x;
|
|
|
|
}
|
2020-11-21 23:24:07 +01:00
|
|
|
else if (m == 0)
|
|
|
|
{
|
|
|
|
/* horizontal - use "y = C" */
|
|
|
|
result->A = 0.0;
|
|
|
|
result->B = -1.0;
|
|
|
|
result->C = pt->y;
|
|
|
|
}
|
1999-12-21 18:01:44 +01:00
|
|
|
else
|
2010-11-10 22:51:39 +01:00
|
|
|
{
|
|
|
|
/* use "mx - y + yinter = 0" */
|
|
|
|
result->A = m;
|
|
|
|
result->B = -1.0;
|
2018-08-16 19:56:11 +02:00
|
|
|
result->C = float8_mi(pt->y, float8_mul(m, pt->x));
|
2018-07-29 20:35:18 +02:00
|
|
|
/* on some platforms, the preceding expression tends to produce -0 */
|
|
|
|
if (result->C == 0.0)
|
|
|
|
result->C = 0.0;
|
2010-11-10 22:51:39 +01:00
|
|
|
}
|
2000-07-30 22:44:02 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* line_construct_pp()
|
|
|
|
* two points
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
line_construct_pp(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
Point *pt1 = PG_GETARG_POINT_P(0);
|
|
|
|
Point *pt2 = PG_GETARG_POINT_P(1);
|
|
|
|
LINE *result = (LINE *) palloc(sizeof(LINE));
|
|
|
|
|
2018-09-26 10:25:24 +02:00
|
|
|
if (point_eq_point(pt1, pt2))
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
|
|
|
|
errmsg("invalid line specification: must be two distinct points")));
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
line_construct(result, pt1, point_sl(pt1, pt2));
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_LINE_P(result);
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
|
|
|
* Relative position routines.
|
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
line_intersect(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LINE *l1 = PG_GETARG_LINE_P(0);
|
|
|
|
LINE *l2 = PG_GETARG_LINE_P(1);
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
PG_RETURN_BOOL(line_interpt_line(NULL, l1, l2));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
line_parallel(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LINE *l1 = PG_GETARG_LINE_P(0);
|
|
|
|
LINE *l2 = PG_GETARG_LINE_P(1);
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
PG_RETURN_BOOL(!line_interpt_line(NULL, l1, l2));
|
2000-07-30 22:44:02 +02:00
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
line_perp(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LINE *l1 = PG_GETARG_LINE_P(0);
|
|
|
|
LINE *l2 = PG_GETARG_LINE_P(1);
|
|
|
|
|
1997-07-29 18:08:18 +02:00
|
|
|
if (FPzero(l1->A))
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOOL(FPzero(l2->B));
|
2018-09-26 10:25:24 +02:00
|
|
|
if (FPzero(l2->A))
|
|
|
|
PG_RETURN_BOOL(FPzero(l1->B));
|
|
|
|
if (FPzero(l1->B))
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOOL(FPzero(l2->A));
|
2018-09-26 10:25:24 +02:00
|
|
|
if (FPzero(l2->B))
|
|
|
|
PG_RETURN_BOOL(FPzero(l1->A));
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2018-09-26 10:25:24 +02:00
|
|
|
PG_RETURN_BOOL(FPeq(float8_div(float8_mul(l1->A, l2->A),
|
|
|
|
float8_mul(l1->B, l2->B)), -1.0));
|
2000-07-30 22:44:02 +02:00
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
line_vertical(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LINE *line = PG_GETARG_LINE_P(0);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPzero(line->B));
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
line_horizontal(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LINE *line = PG_GETARG_LINE_P(0);
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOOL(FPzero(line->A));
|
|
|
|
}
|
|
|
|
|
2018-08-16 19:56:11 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Check whether the two lines are the same
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
line_eq(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LINE *l1 = PG_GETARG_LINE_P(0);
|
|
|
|
LINE *l2 = PG_GETARG_LINE_P(1);
|
2018-08-16 19:56:11 +02:00
|
|
|
float8 ratio;
|
|
|
|
|
Fix FPeq() and friends to get the right answers for infinities.
"FPeq(infinity, infinity)" returned false, on account of getting NaN
when it subtracts the two inputs. Fix that by adding a separate
check for exact equality.
FPle() and FPge() similarly got the wrong answer for two like-signed
infinities. In those cases, we can just rearrange the comparisons
to avoid potentially subtracting infinities.
While the sibling functions FPne() etc accidentally gave the right
answers even with the internal NaN results, it seems best to make
similar adjustments to them to avoid depending on this.
FPeq() has to be converted to an inline function to avoid double
evaluations of its arguments, and I did the same for the others
just for consistency.
In passing, make the handling of NaN cases in line_eq() and
point_eq_point() simpler and easier to reason about, and perhaps
faster.
This results in just one visible regression test change: slope()
now gives DBL_MAX for two inputs of (inf,1e300), which is consistent
with what it does for (1e300,inf), so that seems like a bug fix.
Discussion: https://postgr.es/m/CAGf+fX70rWFOk5cd00uMfa__0yP+vtQg5ck7c2Onb-Yczp0URA@mail.gmail.com
2020-11-21 22:46:43 +01:00
|
|
|
/* If any NaNs are involved, insist on exact equality */
|
|
|
|
if (unlikely(isnan(l1->A) || isnan(l1->B) || isnan(l1->C) ||
|
|
|
|
isnan(l2->A) || isnan(l2->B) || isnan(l2->C)))
|
|
|
|
{
|
|
|
|
PG_RETURN_BOOL(float8_eq(l1->A, l2->A) &&
|
|
|
|
float8_eq(l1->B, l2->B) &&
|
|
|
|
float8_eq(l1->C, l2->C));
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Otherwise, lines whose parameters are proportional are the same */
|
|
|
|
if (!FPzero(l2->A))
|
2018-08-16 19:56:11 +02:00
|
|
|
ratio = float8_div(l1->A, l2->A);
|
Fix FPeq() and friends to get the right answers for infinities.
"FPeq(infinity, infinity)" returned false, on account of getting NaN
when it subtracts the two inputs. Fix that by adding a separate
check for exact equality.
FPle() and FPge() similarly got the wrong answer for two like-signed
infinities. In those cases, we can just rearrange the comparisons
to avoid potentially subtracting infinities.
While the sibling functions FPne() etc accidentally gave the right
answers even with the internal NaN results, it seems best to make
similar adjustments to them to avoid depending on this.
FPeq() has to be converted to an inline function to avoid double
evaluations of its arguments, and I did the same for the others
just for consistency.
In passing, make the handling of NaN cases in line_eq() and
point_eq_point() simpler and easier to reason about, and perhaps
faster.
This results in just one visible regression test change: slope()
now gives DBL_MAX for two inputs of (inf,1e300), which is consistent
with what it does for (1e300,inf), so that seems like a bug fix.
Discussion: https://postgr.es/m/CAGf+fX70rWFOk5cd00uMfa__0yP+vtQg5ck7c2Onb-Yczp0URA@mail.gmail.com
2020-11-21 22:46:43 +01:00
|
|
|
else if (!FPzero(l2->B))
|
2018-08-16 19:56:11 +02:00
|
|
|
ratio = float8_div(l1->B, l2->B);
|
Fix FPeq() and friends to get the right answers for infinities.
"FPeq(infinity, infinity)" returned false, on account of getting NaN
when it subtracts the two inputs. Fix that by adding a separate
check for exact equality.
FPle() and FPge() similarly got the wrong answer for two like-signed
infinities. In those cases, we can just rearrange the comparisons
to avoid potentially subtracting infinities.
While the sibling functions FPne() etc accidentally gave the right
answers even with the internal NaN results, it seems best to make
similar adjustments to them to avoid depending on this.
FPeq() has to be converted to an inline function to avoid double
evaluations of its arguments, and I did the same for the others
just for consistency.
In passing, make the handling of NaN cases in line_eq() and
point_eq_point() simpler and easier to reason about, and perhaps
faster.
This results in just one visible regression test change: slope()
now gives DBL_MAX for two inputs of (inf,1e300), which is consistent
with what it does for (1e300,inf), so that seems like a bug fix.
Discussion: https://postgr.es/m/CAGf+fX70rWFOk5cd00uMfa__0yP+vtQg5ck7c2Onb-Yczp0URA@mail.gmail.com
2020-11-21 22:46:43 +01:00
|
|
|
else if (!FPzero(l2->C))
|
2018-08-16 19:56:11 +02:00
|
|
|
ratio = float8_div(l1->C, l2->C);
|
1996-07-09 08:22:35 +02:00
|
|
|
else
|
2018-08-16 19:56:11 +02:00
|
|
|
ratio = 1.0;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
Fix FPeq() and friends to get the right answers for infinities.
"FPeq(infinity, infinity)" returned false, on account of getting NaN
when it subtracts the two inputs. Fix that by adding a separate
check for exact equality.
FPle() and FPge() similarly got the wrong answer for two like-signed
infinities. In those cases, we can just rearrange the comparisons
to avoid potentially subtracting infinities.
While the sibling functions FPne() etc accidentally gave the right
answers even with the internal NaN results, it seems best to make
similar adjustments to them to avoid depending on this.
FPeq() has to be converted to an inline function to avoid double
evaluations of its arguments, and I did the same for the others
just for consistency.
In passing, make the handling of NaN cases in line_eq() and
point_eq_point() simpler and easier to reason about, and perhaps
faster.
This results in just one visible regression test change: slope()
now gives DBL_MAX for two inputs of (inf,1e300), which is consistent
with what it does for (1e300,inf), so that seems like a bug fix.
Discussion: https://postgr.es/m/CAGf+fX70rWFOk5cd00uMfa__0yP+vtQg5ck7c2Onb-Yczp0URA@mail.gmail.com
2020-11-21 22:46:43 +01:00
|
|
|
PG_RETURN_BOOL(FPeq(l1->A, float8_mul(ratio, l2->A)) &&
|
|
|
|
FPeq(l1->B, float8_mul(ratio, l2->B)) &&
|
|
|
|
FPeq(l1->C, float8_mul(ratio, l2->C)));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
|
|
|
* Line arithmetic routines.
|
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
2018-09-26 10:25:24 +02:00
|
|
|
/*
|
|
|
|
* Return slope of the line
|
|
|
|
*/
|
|
|
|
static inline float8
|
|
|
|
line_sl(LINE *line)
|
|
|
|
{
|
|
|
|
if (FPzero(line->A))
|
|
|
|
return 0.0;
|
|
|
|
if (FPzero(line->B))
|
2020-11-21 23:24:07 +01:00
|
|
|
return get_float8_infinity();
|
2018-09-26 10:25:24 +02:00
|
|
|
return float8_div(line->A, -line->B);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
/*
|
|
|
|
* Return inverse slope of the line
|
|
|
|
*/
|
|
|
|
static inline float8
|
|
|
|
line_invsl(LINE *line)
|
|
|
|
{
|
|
|
|
if (FPzero(line->A))
|
2020-11-21 23:24:07 +01:00
|
|
|
return get_float8_infinity();
|
2018-07-29 02:02:48 +02:00
|
|
|
if (FPzero(line->B))
|
|
|
|
return 0.0;
|
2018-08-16 19:56:11 +02:00
|
|
|
return float8_div(line->B, line->A);
|
2018-07-29 02:02:48 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
1998-05-10 00:39:55 +02:00
|
|
|
/* line_distance()
|
|
|
|
* Distance between two lines.
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
line_distance(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LINE *l1 = PG_GETARG_LINE_P(0);
|
|
|
|
LINE *l2 = PG_GETARG_LINE_P(1);
|
2018-09-26 10:25:24 +02:00
|
|
|
float8 ratio;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
if (line_interpt_line(NULL, l1, l2)) /* intersecting? */
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_FLOAT8(0.0);
|
2018-09-26 10:25:24 +02:00
|
|
|
|
|
|
|
if (!FPzero(l1->A) && !isnan(l1->A) && !FPzero(l2->A) && !isnan(l2->A))
|
|
|
|
ratio = float8_div(l1->A, l2->A);
|
|
|
|
else if (!FPzero(l1->B) && !isnan(l1->B) && !FPzero(l2->B) && !isnan(l2->B))
|
|
|
|
ratio = float8_div(l1->B, l2->B);
|
|
|
|
else
|
|
|
|
ratio = 1.0;
|
|
|
|
|
|
|
|
PG_RETURN_FLOAT8(float8_div(fabs(float8_mi(l1->C,
|
|
|
|
float8_mul(ratio, l2->C))),
|
|
|
|
HYPOT(l1->A, l1->B)));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
1997-07-29 18:08:18 +02:00
|
|
|
/* line_interpt()
|
|
|
|
* Point where two lines l1, l2 intersect (if any)
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
line_interpt(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
LINE *l1 = PG_GETARG_LINE_P(0);
|
|
|
|
LINE *l2 = PG_GETARG_LINE_P(1);
|
|
|
|
Point *result;
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
result = (Point *) palloc(sizeof(Point));
|
2000-07-30 22:44:02 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
if (!line_interpt_line(result, l1, l2))
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_NULL();
|
|
|
|
PG_RETURN_POINT_P(result);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Internal version of line_interpt
|
|
|
|
*
|
2018-11-15 16:08:03 +01:00
|
|
|
* Return whether two lines intersect. If *result is not NULL, it is set to
|
|
|
|
* the intersection point.
|
2018-07-29 02:02:48 +02:00
|
|
|
*
|
|
|
|
* NOTE: If the lines are identical then we will find they are parallel
|
|
|
|
* and report "no intersection". This is a little weird, but since
|
|
|
|
* there's no *unique* intersection, maybe it's appropriate behavior.
|
2018-08-16 19:56:11 +02:00
|
|
|
*
|
|
|
|
* If the lines have NaN constants, we will return true, and the intersection
|
|
|
|
* point would have NaN coordinates. We shouldn't return false in this case
|
|
|
|
* because that would mean the lines are parallel.
|
2000-07-30 22:44:02 +02:00
|
|
|
*/
|
2018-07-29 02:02:48 +02:00
|
|
|
static bool
|
|
|
|
line_interpt_line(Point *result, LINE *l1, LINE *l2)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2018-08-16 19:56:11 +02:00
|
|
|
float8 x,
|
1997-07-29 18:08:18 +02:00
|
|
|
y;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2018-09-26 10:25:24 +02:00
|
|
|
if (!FPzero(l1->B))
|
1997-07-29 18:08:18 +02:00
|
|
|
{
|
2018-09-26 10:25:24 +02:00
|
|
|
if (FPeq(l2->A, float8_mul(l1->A, float8_div(l2->B, l1->B))))
|
2018-07-29 02:02:48 +02:00
|
|
|
return false;
|
|
|
|
|
2018-09-26 10:25:24 +02:00
|
|
|
x = float8_div(float8_mi(float8_mul(l1->B, l2->C),
|
|
|
|
float8_mul(l2->B, l1->C)),
|
|
|
|
float8_mi(float8_mul(l1->A, l2->B),
|
|
|
|
float8_mul(l2->A, l1->B)));
|
|
|
|
y = float8_div(-float8_pl(float8_mul(l1->A, x), l1->C), l1->B);
|
1997-07-29 18:08:18 +02:00
|
|
|
}
|
2018-09-26 10:25:24 +02:00
|
|
|
else if (!FPzero(l2->B))
|
1997-07-29 18:08:18 +02:00
|
|
|
{
|
2018-09-26 10:25:24 +02:00
|
|
|
if (FPeq(l1->A, float8_mul(l2->A, float8_div(l1->B, l2->B))))
|
2018-07-29 02:02:48 +02:00
|
|
|
return false;
|
|
|
|
|
2018-09-26 10:25:24 +02:00
|
|
|
x = float8_div(float8_mi(float8_mul(l2->B, l1->C),
|
|
|
|
float8_mul(l1->B, l2->C)),
|
|
|
|
float8_mi(float8_mul(l2->A, l1->B),
|
|
|
|
float8_mul(l1->A, l2->B)));
|
|
|
|
y = float8_div(-float8_pl(float8_mul(l2->A, x), l2->C), l2->B);
|
1997-09-05 20:13:45 +02:00
|
|
|
}
|
2018-09-26 10:25:24 +02:00
|
|
|
else
|
|
|
|
return false;
|
|
|
|
|
|
|
|
/* On some platforms, the preceding expressions tend to produce -0. */
|
|
|
|
if (x == 0.0)
|
|
|
|
x = 0.0;
|
|
|
|
if (y == 0.0)
|
|
|
|
y = 0.0;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
if (result != NULL)
|
|
|
|
point_construct(result, x, y);
|
2000-07-30 22:44:02 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
return true;
|
2000-07-30 22:44:02 +02:00
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
/***********************************************************************
|
|
|
|
**
|
|
|
|
** Routines for 2D paths (sequences of line segments, also
|
|
|
|
** called `polylines').
|
|
|
|
**
|
|
|
|
** This is not a general package for geometric paths,
|
|
|
|
** which of course include polygons; the emphasis here
|
|
|
|
** is on (for example) usefulness in wire layout.
|
|
|
|
**
|
|
|
|
***********************************************************************/
|
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
|
|
|
* String to path / path to string conversion.
|
|
|
|
* External format:
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
* "((xcoord, ycoord),... )"
|
|
|
|
* "[(xcoord, ycoord),... ]"
|
|
|
|
* "(xcoord, ycoord),... "
|
|
|
|
* "[xcoord, ycoord,... ]"
|
|
|
|
* Also support older format:
|
1996-07-09 08:22:35 +02:00
|
|
|
* "(closed, npts, xcoord, ycoord,... )"
|
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
2004-05-26 20:35:51 +02:00
|
|
|
Datum
|
|
|
|
path_area(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
PATH *path = PG_GETARG_PATH_P(0);
|
2018-08-16 19:56:11 +02:00
|
|
|
float8 area = 0.0;
|
2004-05-26 20:35:51 +02:00
|
|
|
int i,
|
|
|
|
j;
|
|
|
|
|
|
|
|
if (!path->closed)
|
|
|
|
PG_RETURN_NULL();
|
|
|
|
|
|
|
|
for (i = 0; i < path->npts; i++)
|
|
|
|
{
|
|
|
|
j = (i + 1) % path->npts;
|
2018-08-16 19:56:11 +02:00
|
|
|
area = float8_pl(area, float8_mul(path->p[i].x, path->p[j].y));
|
|
|
|
area = float8_mi(area, float8_mul(path->p[i].y, path->p[j].x));
|
2004-05-26 20:35:51 +02:00
|
|
|
}
|
|
|
|
|
2018-08-16 19:56:11 +02:00
|
|
|
PG_RETURN_FLOAT8(float8_div(fabs(area), 2.0));
|
2004-05-26 20:35:51 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
path_in(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
char *str = PG_GETARG_CSTRING(0);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
PATH *path;
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
bool isopen;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
char *s;
|
|
|
|
int npts;
|
|
|
|
int size;
|
2014-02-17 15:33:31 +01:00
|
|
|
int base_size;
|
1997-06-03 16:01:22 +02:00
|
|
|
int depth = 0;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
|
|
|
if ((npts = pair_count(str, ',')) <= 0)
|
2003-07-27 06:53:12 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
errmsg("invalid input syntax for type %s: \"%s\"",
|
|
|
|
"path", str)));
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
|
|
|
s = str;
|
2000-12-03 21:45:40 +01:00
|
|
|
while (isspace((unsigned char) *s))
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
s++;
|
1997-06-03 16:01:22 +02:00
|
|
|
|
|
|
|
/* skip single leading paren */
|
|
|
|
if ((*s == LDELIM) && (strrchr(s, LDELIM) == s))
|
|
|
|
{
|
|
|
|
s++;
|
|
|
|
depth++;
|
1997-09-05 20:13:45 +02:00
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2014-02-17 15:33:31 +01:00
|
|
|
base_size = sizeof(path->p[0]) * npts;
|
2015-02-20 06:11:42 +01:00
|
|
|
size = offsetof(PATH, p) + base_size;
|
2014-02-17 15:33:31 +01:00
|
|
|
|
|
|
|
/* Check for integer overflow */
|
|
|
|
if (base_size / npts != sizeof(path->p[0]) || size <= base_size)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
|
|
|
|
errmsg("too many points requested")));
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
path = (PATH *) palloc(size);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2007-02-28 00:48:10 +01:00
|
|
|
SET_VARSIZE(path, size);
|
1997-06-03 16:01:22 +02:00
|
|
|
path->npts = npts;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
path_decode(s, true, npts, &(path->p[0]), &isopen, &s, "path", str);
|
|
|
|
|
|
|
|
if (depth >= 1)
|
|
|
|
{
|
|
|
|
if (*s++ != RDELIM)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
|
|
|
|
errmsg("invalid input syntax for type %s: \"%s\"",
|
|
|
|
"path", str)));
|
|
|
|
while (isspace((unsigned char) *s))
|
|
|
|
s++;
|
|
|
|
}
|
|
|
|
if (*s != '\0')
|
2003-07-27 06:53:12 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
errmsg("invalid input syntax for type %s: \"%s\"",
|
|
|
|
"path", str)));
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-06-03 16:01:22 +02:00
|
|
|
path->closed = (!isopen);
|
2008-04-12 00:52:05 +02:00
|
|
|
/* prevent instability in unused pad bytes */
|
|
|
|
path->dummy = 0;
|
1997-06-03 16:01:22 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_PATH_P(path);
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
path_out(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
PATH *path = PG_GETARG_PATH_P(0);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2013-07-09 04:42:39 +02:00
|
|
|
PG_RETURN_CSTRING(path_encode(path->closed ? PATH_CLOSED : PATH_OPEN, path->npts, path->p));
|
2000-07-29 20:46:12 +02:00
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2003-05-13 20:03:08 +02:00
|
|
|
/*
|
|
|
|
* path_recv - converts external binary format to path
|
|
|
|
*
|
|
|
|
* External representation is closed flag (a boolean byte), int32 number
|
|
|
|
* of points, and the points.
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
path_recv(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
StringInfo buf = (StringInfo) PG_GETARG_POINTER(0);
|
|
|
|
PATH *path;
|
|
|
|
int closed;
|
|
|
|
int32 npts;
|
|
|
|
int32 i;
|
|
|
|
int size;
|
|
|
|
|
|
|
|
closed = pq_getmsgbyte(buf);
|
|
|
|
npts = pq_getmsgint(buf, sizeof(int32));
|
2015-02-20 06:11:42 +01:00
|
|
|
if (npts <= 0 || npts >= (int32) ((INT_MAX - offsetof(PATH, p)) / sizeof(Point)))
|
2003-07-27 06:53:12 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_BINARY_REPRESENTATION),
|
2003-09-29 02:05:25 +02:00
|
|
|
errmsg("invalid number of points in external \"path\" value")));
|
2003-05-13 20:03:08 +02:00
|
|
|
|
2015-02-20 06:11:42 +01:00
|
|
|
size = offsetof(PATH, p) + sizeof(path->p[0]) * npts;
|
2003-05-13 20:03:08 +02:00
|
|
|
path = (PATH *) palloc(size);
|
|
|
|
|
2007-02-28 00:48:10 +01:00
|
|
|
SET_VARSIZE(path, size);
|
2003-05-13 20:03:08 +02:00
|
|
|
path->npts = npts;
|
|
|
|
path->closed = (closed ? 1 : 0);
|
Fix array- and path-creating functions to ensure padding bytes are zeroes.
Per recent discussion, it's important for all computed datums (not only the
results of input functions) to not contain any ill-defined (uninitialized)
bits. Failing to ensure that can result in equal() reporting that
semantically indistinguishable Consts are not equal, which in turn leads to
bizarre and undesirable planner behavior, such as in a recent example from
David Johnston. We might eventually try to fix this in a general manner by
allowing datatypes to define identity-testing functions, but for now the
path of least resistance is to expect datatypes to force all unused bits
into consistent states.
Per some testing by Noah Misch, array and path functions seem to be the
only ones presenting risks at the moment, so I looked through all the
functions in adt/array*.c and geo_ops.c and fixed them as necessary. In
the array functions, the easiest/safest fix is to allocate result arrays
with palloc0 instead of palloc. Possibly in future someone will want to
look into whether we can just zero the padding bytes, but that looks too
complex for a back-patchable fix. In the path functions, we already had a
precedent in path_in for just zeroing the one known pad field, so duplicate
that code as needed.
Back-patch to all supported branches.
2011-04-27 19:58:36 +02:00
|
|
|
/* prevent instability in unused pad bytes */
|
|
|
|
path->dummy = 0;
|
2003-05-13 20:03:08 +02:00
|
|
|
|
|
|
|
for (i = 0; i < npts; i++)
|
|
|
|
{
|
|
|
|
path->p[i].x = pq_getmsgfloat8(buf);
|
|
|
|
path->p[i].y = pq_getmsgfloat8(buf);
|
|
|
|
}
|
|
|
|
|
|
|
|
PG_RETURN_PATH_P(path);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* path_send - converts path to binary format
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
path_send(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
PATH *path = PG_GETARG_PATH_P(0);
|
|
|
|
StringInfoData buf;
|
|
|
|
int32 i;
|
|
|
|
|
|
|
|
pq_begintypsend(&buf);
|
|
|
|
pq_sendbyte(&buf, path->closed ? 1 : 0);
|
2017-10-12 06:00:46 +02:00
|
|
|
pq_sendint32(&buf, path->npts);
|
2003-05-13 20:03:08 +02:00
|
|
|
for (i = 0; i < path->npts; i++)
|
|
|
|
{
|
|
|
|
pq_sendfloat8(&buf, path->p[i].x);
|
|
|
|
pq_sendfloat8(&buf, path->p[i].y);
|
|
|
|
}
|
|
|
|
PG_RETURN_BYTEA_P(pq_endtypsend(&buf));
|
|
|
|
}
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
|
|
|
* Relational operators.
|
|
|
|
* These are based on the path cardinality,
|
|
|
|
* as stupid as that sounds.
|
|
|
|
*
|
|
|
|
* Better relops and access methods coming soon.
|
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
path_n_lt(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
PATH *p1 = PG_GETARG_PATH_P(0);
|
|
|
|
PATH *p2 = PG_GETARG_PATH_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(p1->npts < p2->npts);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
path_n_gt(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
PATH *p1 = PG_GETARG_PATH_P(0);
|
|
|
|
PATH *p2 = PG_GETARG_PATH_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(p1->npts > p2->npts);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
path_n_eq(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
PATH *p1 = PG_GETARG_PATH_P(0);
|
|
|
|
PATH *p2 = PG_GETARG_PATH_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(p1->npts == p2->npts);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
path_n_le(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
PATH *p1 = PG_GETARG_PATH_P(0);
|
|
|
|
PATH *p2 = PG_GETARG_PATH_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(p1->npts <= p2->npts);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
path_n_ge(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
PATH *p1 = PG_GETARG_PATH_P(0);
|
|
|
|
PATH *p2 = PG_GETARG_PATH_P(1);
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_BOOL(p1->npts >= p2->npts);
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
|
|
|
* Conversion operators.
|
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
path_isclosed(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
PATH *path = PG_GETARG_PATH_P(0);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_BOOL(path->closed);
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
path_isopen(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
PATH *path = PG_GETARG_PATH_P(0);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_BOOL(!path->closed);
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
path_npoints(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
PATH *path = PG_GETARG_PATH_P(0);
|
1997-06-03 16:01:22 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_INT32(path->npts);
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
path_close(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
PATH *path = PG_GETARG_PATH_P_COPY(0);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2017-08-16 06:22:32 +02:00
|
|
|
path->closed = true;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_PATH_P(path);
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
path_open(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
PATH *path = PG_GETARG_PATH_P_COPY(0);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2017-08-16 06:22:32 +02:00
|
|
|
path->closed = false;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_PATH_P(path);
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/* path_inter -
|
|
|
|
* Does p1 intersect p2 at any point?
|
|
|
|
* Use bounding boxes for a quick (O(n)) check, then do a
|
|
|
|
* O(n^2) iterative edge check.
|
|
|
|
*/
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
path_inter(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
PATH *p1 = PG_GETARG_PATH_P(0);
|
|
|
|
PATH *p2 = PG_GETARG_PATH_P(1);
|
1996-07-09 08:22:35 +02:00
|
|
|
BOX b1,
|
|
|
|
b2;
|
|
|
|
int i,
|
|
|
|
j;
|
|
|
|
LSEG seg1,
|
|
|
|
seg2;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
Assert(p1->npts > 0 && p2->npts > 0);
|
2001-10-13 19:40:24 +02:00
|
|
|
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
b1.high.x = b1.low.x = p1->p[0].x;
|
|
|
|
b1.high.y = b1.low.y = p1->p[0].y;
|
|
|
|
for (i = 1; i < p1->npts; i++)
|
|
|
|
{
|
2018-08-16 19:56:11 +02:00
|
|
|
b1.high.x = float8_max(p1->p[i].x, b1.high.x);
|
|
|
|
b1.high.y = float8_max(p1->p[i].y, b1.high.y);
|
|
|
|
b1.low.x = float8_min(p1->p[i].x, b1.low.x);
|
|
|
|
b1.low.y = float8_min(p1->p[i].y, b1.low.y);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
b2.high.x = b2.low.x = p2->p[0].x;
|
|
|
|
b2.high.y = b2.low.y = p2->p[0].y;
|
|
|
|
for (i = 1; i < p2->npts; i++)
|
|
|
|
{
|
2018-08-16 19:56:11 +02:00
|
|
|
b2.high.x = float8_max(p2->p[i].x, b2.high.x);
|
|
|
|
b2.high.y = float8_max(p2->p[i].y, b2.high.y);
|
|
|
|
b2.low.x = float8_min(p2->p[i].x, b2.low.x);
|
|
|
|
b2.low.y = float8_min(p2->p[i].y, b2.low.y);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
2000-07-30 22:44:02 +02:00
|
|
|
if (!box_ov(&b1, &b2))
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_BOOL(false);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/* pairwise check lseg intersections */
|
2001-10-13 19:40:24 +02:00
|
|
|
for (i = 0; i < p1->npts; i++)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2001-10-13 19:40:24 +02:00
|
|
|
int iprev;
|
|
|
|
|
|
|
|
if (i > 0)
|
|
|
|
iprev = i - 1;
|
|
|
|
else
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2001-10-13 19:40:24 +02:00
|
|
|
if (!p1->closed)
|
|
|
|
continue;
|
|
|
|
iprev = p1->npts - 1; /* include the closure segment */
|
|
|
|
}
|
|
|
|
|
|
|
|
for (j = 0; j < p2->npts; j++)
|
|
|
|
{
|
|
|
|
int jprev;
|
|
|
|
|
|
|
|
if (j > 0)
|
|
|
|
jprev = j - 1;
|
|
|
|
else
|
|
|
|
{
|
|
|
|
if (!p2->closed)
|
|
|
|
continue;
|
|
|
|
jprev = p2->npts - 1; /* include the closure segment */
|
|
|
|
}
|
|
|
|
|
|
|
|
statlseg_construct(&seg1, &p1->p[iprev], &p1->p[i]);
|
|
|
|
statlseg_construct(&seg2, &p2->p[jprev], &p2->p[j]);
|
2018-07-29 02:02:48 +02:00
|
|
|
if (lseg_interpt_lseg(NULL, &seg1, &seg2))
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_BOOL(true);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/* if we dropped through, no two segs intersected */
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_BOOL(false);
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
1998-02-03 16:55:58 +01:00
|
|
|
/* path_distance()
|
|
|
|
* This essentially does a cartesian product of the lsegs in the
|
2000-07-30 22:44:02 +02:00
|
|
|
* two paths, and finds the min distance between any two lsegs
|
1998-02-03 16:55:58 +01:00
|
|
|
*/
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
path_distance(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
PATH *p1 = PG_GETARG_PATH_P(0);
|
|
|
|
PATH *p2 = PG_GETARG_PATH_P(1);
|
2000-07-30 22:44:02 +02:00
|
|
|
float8 min = 0.0; /* initialize to keep compiler quiet */
|
2001-10-13 19:40:24 +02:00
|
|
|
bool have_min = false;
|
2000-07-29 20:46:12 +02:00
|
|
|
float8 tmp;
|
1996-07-09 08:22:35 +02:00
|
|
|
int i,
|
|
|
|
j;
|
|
|
|
LSEG seg1,
|
|
|
|
seg2;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2001-10-13 19:40:24 +02:00
|
|
|
for (i = 0; i < p1->npts; i++)
|
2000-07-29 20:46:12 +02:00
|
|
|
{
|
2001-10-13 19:40:24 +02:00
|
|
|
int iprev;
|
|
|
|
|
|
|
|
if (i > 0)
|
|
|
|
iprev = i - 1;
|
|
|
|
else
|
|
|
|
{
|
|
|
|
if (!p1->closed)
|
|
|
|
continue;
|
|
|
|
iprev = p1->npts - 1; /* include the closure segment */
|
|
|
|
}
|
|
|
|
|
|
|
|
for (j = 0; j < p2->npts; j++)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2001-10-13 19:40:24 +02:00
|
|
|
int jprev;
|
|
|
|
|
|
|
|
if (j > 0)
|
|
|
|
jprev = j - 1;
|
|
|
|
else
|
|
|
|
{
|
|
|
|
if (!p2->closed)
|
|
|
|
continue;
|
|
|
|
jprev = p2->npts - 1; /* include the closure segment */
|
|
|
|
}
|
|
|
|
|
|
|
|
statlseg_construct(&seg1, &p1->p[iprev], &p1->p[i]);
|
|
|
|
statlseg_construct(&seg2, &p2->p[jprev], &p2->p[j]);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
tmp = lseg_closept_lseg(NULL, &seg1, &seg2);
|
2018-08-16 19:56:11 +02:00
|
|
|
if (!have_min || float8_lt(tmp, min))
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
min = tmp;
|
|
|
|
have_min = true;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
}
|
1997-09-05 20:13:45 +02:00
|
|
|
}
|
2000-07-29 20:46:12 +02:00
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
if (!have_min)
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_NULL();
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_FLOAT8(min);
|
2000-07-29 20:46:12 +02:00
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
|
|
|
* "Arithmetic" operations.
|
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
path_length(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
PATH *path = PG_GETARG_PATH_P(0);
|
2001-10-13 19:40:24 +02:00
|
|
|
float8 result = 0.0;
|
1997-07-29 18:08:18 +02:00
|
|
|
int i;
|
|
|
|
|
2001-10-13 19:40:24 +02:00
|
|
|
for (i = 0; i < path->npts; i++)
|
|
|
|
{
|
|
|
|
int iprev;
|
|
|
|
|
|
|
|
if (i > 0)
|
|
|
|
iprev = i - 1;
|
|
|
|
else
|
|
|
|
{
|
|
|
|
if (!path->closed)
|
|
|
|
continue;
|
|
|
|
iprev = path->npts - 1; /* include the closure segment */
|
|
|
|
}
|
|
|
|
|
2018-08-16 19:56:11 +02:00
|
|
|
result = float8_pl(result, point_dt(&path->p[iprev], &path->p[i]));
|
2001-10-13 19:40:24 +02:00
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_FLOAT8(result);
|
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/***********************************************************************
|
|
|
|
**
|
|
|
|
** Routines for 2D points.
|
|
|
|
**
|
|
|
|
***********************************************************************/
|
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
|
|
|
* String to point, point to string conversion.
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
* External format:
|
|
|
|
* "(x,y)"
|
|
|
|
* "x,y"
|
1996-07-09 08:22:35 +02:00
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
point_in(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
char *str = PG_GETARG_CSTRING(0);
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
Point *point = (Point *) palloc(sizeof(Point));
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
pair_decode(str, &point->x, &point->y, NULL, "point", str);
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_POINT_P(point);
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
point_out(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *pt = PG_GETARG_POINT_P(0);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2013-07-09 04:42:39 +02:00
|
|
|
PG_RETURN_CSTRING(path_encode(PATH_NONE, 1, pt));
|
2000-07-30 22:44:02 +02:00
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2003-05-09 23:19:50 +02:00
|
|
|
/*
|
|
|
|
* point_recv - converts external binary format to point
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
point_recv(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
StringInfo buf = (StringInfo) PG_GETARG_POINTER(0);
|
|
|
|
Point *point;
|
|
|
|
|
|
|
|
point = (Point *) palloc(sizeof(Point));
|
|
|
|
point->x = pq_getmsgfloat8(buf);
|
|
|
|
point->y = pq_getmsgfloat8(buf);
|
|
|
|
PG_RETURN_POINT_P(point);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* point_send - converts point to binary format
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
point_send(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
Point *pt = PG_GETARG_POINT_P(0);
|
|
|
|
StringInfoData buf;
|
|
|
|
|
|
|
|
pq_begintypsend(&buf);
|
|
|
|
pq_sendfloat8(&buf, pt->x);
|
|
|
|
pq_sendfloat8(&buf, pt->y);
|
|
|
|
PG_RETURN_BYTEA_P(pq_endtypsend(&buf));
|
|
|
|
}
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
/*
|
|
|
|
* Initialize a point
|
|
|
|
*/
|
|
|
|
static inline void
|
|
|
|
point_construct(Point *result, float8 x, float8 y)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
|
|
|
result->x = x;
|
|
|
|
result->y = y;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
|
|
|
* Relational operators for Points.
|
|
|
|
* Since we do have a sense of coordinates being
|
|
|
|
* "equal" to a given accuracy (point_vert, point_horiz),
|
|
|
|
* the other ops must preserve that sense. This means
|
|
|
|
* that results may, strictly speaking, be a lie (unless
|
|
|
|
* EPSILON = 0.0).
|
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
point_left(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *pt1 = PG_GETARG_POINT_P(0);
|
|
|
|
Point *pt2 = PG_GETARG_POINT_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPlt(pt1->x, pt2->x));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
point_right(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *pt1 = PG_GETARG_POINT_P(0);
|
|
|
|
Point *pt2 = PG_GETARG_POINT_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPgt(pt1->x, pt2->x));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
point_above(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *pt1 = PG_GETARG_POINT_P(0);
|
|
|
|
Point *pt2 = PG_GETARG_POINT_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPgt(pt1->y, pt2->y));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
point_below(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *pt1 = PG_GETARG_POINT_P(0);
|
|
|
|
Point *pt2 = PG_GETARG_POINT_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPlt(pt1->y, pt2->y));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
point_vert(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *pt1 = PG_GETARG_POINT_P(0);
|
|
|
|
Point *pt2 = PG_GETARG_POINT_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPeq(pt1->x, pt2->x));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
point_horiz(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *pt1 = PG_GETARG_POINT_P(0);
|
|
|
|
Point *pt2 = PG_GETARG_POINT_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPeq(pt1->y, pt2->y));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
point_eq(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *pt1 = PG_GETARG_POINT_P(0);
|
|
|
|
Point *pt2 = PG_GETARG_POINT_P(1);
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
PG_RETURN_BOOL(point_eq_point(pt1, pt2));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
point_ne(PG_FUNCTION_ARGS)
|
1997-09-20 18:22:31 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *pt1 = PG_GETARG_POINT_P(0);
|
|
|
|
Point *pt2 = PG_GETARG_POINT_P(1);
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
PG_RETURN_BOOL(!point_eq_point(pt1, pt2));
|
|
|
|
}
|
|
|
|
|
2018-08-16 19:56:11 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Check whether the two points are the same
|
|
|
|
*/
|
2018-07-29 02:02:48 +02:00
|
|
|
static inline bool
|
|
|
|
point_eq_point(Point *pt1, Point *pt2)
|
|
|
|
{
|
Fix FPeq() and friends to get the right answers for infinities.
"FPeq(infinity, infinity)" returned false, on account of getting NaN
when it subtracts the two inputs. Fix that by adding a separate
check for exact equality.
FPle() and FPge() similarly got the wrong answer for two like-signed
infinities. In those cases, we can just rearrange the comparisons
to avoid potentially subtracting infinities.
While the sibling functions FPne() etc accidentally gave the right
answers even with the internal NaN results, it seems best to make
similar adjustments to them to avoid depending on this.
FPeq() has to be converted to an inline function to avoid double
evaluations of its arguments, and I did the same for the others
just for consistency.
In passing, make the handling of NaN cases in line_eq() and
point_eq_point() simpler and easier to reason about, and perhaps
faster.
This results in just one visible regression test change: slope()
now gives DBL_MAX for two inputs of (inf,1e300), which is consistent
with what it does for (1e300,inf), so that seems like a bug fix.
Discussion: https://postgr.es/m/CAGf+fX70rWFOk5cd00uMfa__0yP+vtQg5ck7c2Onb-Yczp0URA@mail.gmail.com
2020-11-21 22:46:43 +01:00
|
|
|
/* If any NaNs are involved, insist on exact equality */
|
|
|
|
if (unlikely(isnan(pt1->x) || isnan(pt1->y) ||
|
|
|
|
isnan(pt2->x) || isnan(pt2->y)))
|
|
|
|
return (float8_eq(pt1->x, pt2->x) && float8_eq(pt1->y, pt2->y));
|
|
|
|
|
|
|
|
return (FPeq(pt1->x, pt2->x) && FPeq(pt1->y, pt2->y));
|
1997-09-20 18:22:31 +02:00
|
|
|
}
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*----------------------------------------------------------
|
|
|
|
* "Arithmetic" operators on points.
|
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
point_distance(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *pt1 = PG_GETARG_POINT_P(0);
|
|
|
|
Point *pt2 = PG_GETARG_POINT_P(1);
|
1997-05-06 09:27:51 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
PG_RETURN_FLOAT8(point_dt(pt1, pt2));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
static inline float8
|
1996-07-09 08:22:35 +02:00
|
|
|
point_dt(Point *pt1, Point *pt2)
|
|
|
|
{
|
2018-08-16 19:56:11 +02:00
|
|
|
return HYPOT(float8_mi(pt1->x, pt2->x), float8_mi(pt1->y, pt2->y));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
point_slope(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *pt1 = PG_GETARG_POINT_P(0);
|
|
|
|
Point *pt2 = PG_GETARG_POINT_P(1);
|
1997-05-06 09:27:51 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_FLOAT8(point_sl(pt1, pt2));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
/*
|
|
|
|
* Return slope of two points
|
|
|
|
*
|
2020-11-21 23:24:07 +01:00
|
|
|
* Note that this function returns Inf when the points are the same.
|
2018-07-29 02:02:48 +02:00
|
|
|
*/
|
|
|
|
static inline float8
|
1996-07-09 08:22:35 +02:00
|
|
|
point_sl(Point *pt1, Point *pt2)
|
|
|
|
{
|
2018-07-29 02:02:48 +02:00
|
|
|
if (FPeq(pt1->x, pt2->x))
|
2020-11-21 23:24:07 +01:00
|
|
|
return get_float8_infinity();
|
2018-07-29 02:02:48 +02:00
|
|
|
if (FPeq(pt1->y, pt2->y))
|
|
|
|
return 0.0;
|
2018-08-16 19:56:11 +02:00
|
|
|
return float8_div(float8_mi(pt1->y, pt2->y), float8_mi(pt1->x, pt2->x));
|
2018-07-29 02:02:48 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Return inverse slope of two points
|
|
|
|
*
|
|
|
|
* Note that this function returns 0.0 when the points are the same.
|
|
|
|
*/
|
|
|
|
static inline float8
|
|
|
|
point_invsl(Point *pt1, Point *pt2)
|
|
|
|
{
|
|
|
|
if (FPeq(pt1->x, pt2->x))
|
|
|
|
return 0.0;
|
|
|
|
if (FPeq(pt1->y, pt2->y))
|
2020-11-21 23:24:07 +01:00
|
|
|
return get_float8_infinity();
|
2018-08-16 19:56:11 +02:00
|
|
|
return float8_div(float8_mi(pt1->x, pt2->x), float8_mi(pt2->y, pt1->y));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/***********************************************************************
|
|
|
|
**
|
|
|
|
** Routines for 2D line segments.
|
|
|
|
**
|
|
|
|
***********************************************************************/
|
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
|
|
|
* String to lseg, lseg to string conversion.
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
* External forms: "[(x1, y1), (x2, y2)]"
|
|
|
|
* "(x1, y1), (x2, y2)"
|
|
|
|
* "x1, y1, x2, y2"
|
|
|
|
* closed form ok "((x1, y1), (x2, y2))"
|
|
|
|
* (old form) "(x1, y1, x2, y2)"
|
1996-07-09 08:22:35 +02:00
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
lseg_in(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
char *str = PG_GETARG_CSTRING(0);
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
LSEG *lseg = (LSEG *) palloc(sizeof(LSEG));
|
|
|
|
bool isopen;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
path_decode(str, true, 2, &lseg->p[0], &isopen, NULL, "lseg", str);
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_LSEG_P(lseg);
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
lseg_out(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LSEG *ls = PG_GETARG_LSEG_P(0);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
PG_RETURN_CSTRING(path_encode(PATH_OPEN, 2, &ls->p[0]));
|
2000-07-30 22:44:02 +02:00
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2003-05-13 20:03:08 +02:00
|
|
|
/*
|
|
|
|
* lseg_recv - converts external binary format to lseg
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
lseg_recv(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
StringInfo buf = (StringInfo) PG_GETARG_POINTER(0);
|
|
|
|
LSEG *lseg;
|
|
|
|
|
|
|
|
lseg = (LSEG *) palloc(sizeof(LSEG));
|
|
|
|
|
|
|
|
lseg->p[0].x = pq_getmsgfloat8(buf);
|
|
|
|
lseg->p[0].y = pq_getmsgfloat8(buf);
|
|
|
|
lseg->p[1].x = pq_getmsgfloat8(buf);
|
|
|
|
lseg->p[1].y = pq_getmsgfloat8(buf);
|
|
|
|
|
|
|
|
PG_RETURN_LSEG_P(lseg);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* lseg_send - converts lseg to binary format
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
lseg_send(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
LSEG *ls = PG_GETARG_LSEG_P(0);
|
|
|
|
StringInfoData buf;
|
|
|
|
|
|
|
|
pq_begintypsend(&buf);
|
|
|
|
pq_sendfloat8(&buf, ls->p[0].x);
|
|
|
|
pq_sendfloat8(&buf, ls->p[0].y);
|
|
|
|
pq_sendfloat8(&buf, ls->p[1].x);
|
|
|
|
pq_sendfloat8(&buf, ls->p[1].y);
|
|
|
|
PG_RETURN_BYTEA_P(pq_endtypsend(&buf));
|
|
|
|
}
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
/* lseg_construct -
|
|
|
|
* form a LSEG from two Points.
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
lseg_construct(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *pt1 = PG_GETARG_POINT_P(0);
|
|
|
|
Point *pt2 = PG_GETARG_POINT_P(1);
|
|
|
|
LSEG *result = (LSEG *) palloc(sizeof(LSEG));
|
1997-05-06 09:27:51 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
statlseg_construct(result, pt1, pt2);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_LSEG_P(result);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* like lseg_construct, but assume space already allocated */
|
2018-07-29 02:02:48 +02:00
|
|
|
static inline void
|
1997-08-19 23:40:56 +02:00
|
|
|
statlseg_construct(LSEG *lseg, Point *pt1, Point *pt2)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
|
|
|
lseg->p[0].x = pt1->x;
|
|
|
|
lseg->p[0].y = pt1->y;
|
|
|
|
lseg->p[1].x = pt2->x;
|
|
|
|
lseg->p[1].y = pt2->y;
|
|
|
|
}
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Return slope of the line segment
|
|
|
|
*/
|
|
|
|
static inline float8
|
|
|
|
lseg_sl(LSEG *lseg)
|
|
|
|
{
|
|
|
|
return point_sl(&lseg->p[0], &lseg->p[1]);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Return inverse slope of the line segment
|
|
|
|
*/
|
|
|
|
static inline float8
|
|
|
|
lseg_invsl(LSEG *lseg)
|
|
|
|
{
|
|
|
|
return point_invsl(&lseg->p[0], &lseg->p[1]);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
lseg_length(PG_FUNCTION_ARGS)
|
1998-02-03 16:55:58 +01:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LSEG *lseg = PG_GETARG_LSEG_P(0);
|
1998-02-03 16:55:58 +01:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_FLOAT8(point_dt(&lseg->p[0], &lseg->p[1]));
|
|
|
|
}
|
1998-02-03 16:55:58 +01:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*----------------------------------------------------------
|
|
|
|
* Relative position routines.
|
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
** find intersection of the two lines, and see if it falls on
|
|
|
|
** both segments.
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
lseg_intersect(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LSEG *l1 = PG_GETARG_LSEG_P(0);
|
|
|
|
LSEG *l2 = PG_GETARG_LSEG_P(1);
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
PG_RETURN_BOOL(lseg_interpt_lseg(NULL, l1, l2));
|
2000-07-30 22:44:02 +02:00
|
|
|
}
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
lseg_parallel(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LSEG *l1 = PG_GETARG_LSEG_P(0);
|
|
|
|
LSEG *l2 = PG_GETARG_LSEG_P(1);
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
PG_RETURN_BOOL(FPeq(lseg_sl(l1), lseg_sl(l2)));
|
2000-07-30 22:44:02 +02:00
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
/*
|
1998-02-03 16:55:58 +01:00
|
|
|
* Determine if two line segments are perpendicular.
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
lseg_perp(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LSEG *l1 = PG_GETARG_LSEG_P(0);
|
|
|
|
LSEG *l2 = PG_GETARG_LSEG_P(1);
|
1998-02-03 16:55:58 +01:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
PG_RETURN_BOOL(FPeq(lseg_sl(l1), lseg_invsl(l2)));
|
2000-07-30 22:44:02 +02:00
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
lseg_vertical(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LSEG *lseg = PG_GETARG_LSEG_P(0);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPeq(lseg->p[0].x, lseg->p[1].x));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
lseg_horizontal(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LSEG *lseg = PG_GETARG_LSEG_P(0);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPeq(lseg->p[0].y, lseg->p[1].y));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
lseg_eq(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LSEG *l1 = PG_GETARG_LSEG_P(0);
|
|
|
|
LSEG *l2 = PG_GETARG_LSEG_P(1);
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
PG_RETURN_BOOL(point_eq_point(&l1->p[0], &l2->p[0]) &&
|
|
|
|
point_eq_point(&l1->p[1], &l2->p[1]));
|
2000-07-30 22:44:02 +02:00
|
|
|
}
|
1998-02-03 16:55:58 +01:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
lseg_ne(PG_FUNCTION_ARGS)
|
1998-02-03 16:55:58 +01:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LSEG *l1 = PG_GETARG_LSEG_P(0);
|
|
|
|
LSEG *l2 = PG_GETARG_LSEG_P(1);
|
1998-02-03 16:55:58 +01:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
PG_RETURN_BOOL(!point_eq_point(&l1->p[0], &l2->p[0]) ||
|
|
|
|
!point_eq_point(&l1->p[1], &l2->p[1]));
|
2000-07-30 22:44:02 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
Datum
|
|
|
|
lseg_lt(PG_FUNCTION_ARGS)
|
1998-02-03 16:55:58 +01:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LSEG *l1 = PG_GETARG_LSEG_P(0);
|
|
|
|
LSEG *l2 = PG_GETARG_LSEG_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPlt(point_dt(&l1->p[0], &l1->p[1]),
|
|
|
|
point_dt(&l2->p[0], &l2->p[1])));
|
|
|
|
}
|
1998-02-03 16:55:58 +01:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
lseg_le(PG_FUNCTION_ARGS)
|
1998-02-03 16:55:58 +01:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LSEG *l1 = PG_GETARG_LSEG_P(0);
|
|
|
|
LSEG *l2 = PG_GETARG_LSEG_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPle(point_dt(&l1->p[0], &l1->p[1]),
|
|
|
|
point_dt(&l2->p[0], &l2->p[1])));
|
|
|
|
}
|
1998-02-03 16:55:58 +01:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
lseg_gt(PG_FUNCTION_ARGS)
|
1998-02-03 16:55:58 +01:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LSEG *l1 = PG_GETARG_LSEG_P(0);
|
|
|
|
LSEG *l2 = PG_GETARG_LSEG_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPgt(point_dt(&l1->p[0], &l1->p[1]),
|
|
|
|
point_dt(&l2->p[0], &l2->p[1])));
|
|
|
|
}
|
1998-02-03 16:55:58 +01:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
lseg_ge(PG_FUNCTION_ARGS)
|
1998-02-03 16:55:58 +01:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LSEG *l1 = PG_GETARG_LSEG_P(0);
|
|
|
|
LSEG *l2 = PG_GETARG_LSEG_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPge(point_dt(&l1->p[0], &l1->p[1]),
|
|
|
|
point_dt(&l2->p[0], &l2->p[1])));
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
|
|
|
* Line arithmetic routines.
|
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
|
|
|
/* lseg_distance -
|
|
|
|
* If two segments don't intersect, then the closest
|
|
|
|
* point will be from one of the endpoints to the other
|
|
|
|
* segment.
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
lseg_distance(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LSEG *l1 = PG_GETARG_LSEG_P(0);
|
|
|
|
LSEG *l2 = PG_GETARG_LSEG_P(1);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
PG_RETURN_FLOAT8(lseg_closept_lseg(NULL, l1, l2));
|
2000-07-30 22:44:02 +02:00
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
lseg_center(PG_FUNCTION_ARGS)
|
1997-07-29 18:08:18 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LSEG *lseg = PG_GETARG_LSEG_P(0);
|
1997-07-29 18:08:18 +02:00
|
|
|
Point *result;
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
result = (Point *) palloc(sizeof(Point));
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2018-08-16 19:56:11 +02:00
|
|
|
result->x = float8_div(float8_pl(lseg->p[0].x, lseg->p[1].x), 2.0);
|
|
|
|
result->y = float8_div(float8_pl(lseg->p[0].y, lseg->p[1].y), 2.0);
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_POINT_P(result);
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
|
|
|
|
/*
|
2018-11-15 16:08:03 +01:00
|
|
|
* Return whether the two segments intersect. If *result is not NULL,
|
|
|
|
* it is set to the intersection point.
|
2018-07-29 02:02:48 +02:00
|
|
|
*
|
|
|
|
* This function is almost perfectly symmetric, even though it doesn't look
|
|
|
|
* like it. See lseg_interpt_line() for the other half of it.
|
|
|
|
*/
|
|
|
|
static bool
|
|
|
|
lseg_interpt_lseg(Point *result, LSEG *l1, LSEG *l2)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2018-07-29 02:02:48 +02:00
|
|
|
Point interpt;
|
|
|
|
LINE tmp;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
line_construct(&tmp, &l2->p[0], lseg_sl(l2));
|
|
|
|
if (!lseg_interpt_line(&interpt, l1, &tmp))
|
|
|
|
return false;
|
2001-03-22 05:01:46 +01:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
/*
|
2018-07-29 02:02:48 +02:00
|
|
|
* If the line intersection point isn't within l2, there is no valid
|
|
|
|
* segment intersection point at all.
|
2000-07-30 22:44:02 +02:00
|
|
|
*/
|
2018-07-29 02:02:48 +02:00
|
|
|
if (!lseg_contain_point(l2, &interpt))
|
|
|
|
return false;
|
2001-03-22 05:01:46 +01:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
if (result != NULL)
|
|
|
|
*result = interpt;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
return true;
|
2009-07-28 11:48:00 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
Datum
|
|
|
|
lseg_interpt(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
LSEG *l1 = PG_GETARG_LSEG_P(0);
|
|
|
|
LSEG *l2 = PG_GETARG_LSEG_P(1);
|
|
|
|
Point *result;
|
2010-02-26 03:01:40 +01:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
result = (Point *) palloc(sizeof(Point));
|
2009-07-28 11:48:00 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
if (!lseg_interpt_lseg(result, l1, l2))
|
|
|
|
PG_RETURN_NULL();
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_POINT_P(result);
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
/***********************************************************************
|
|
|
|
**
|
|
|
|
** Routines for position comparisons of differently-typed
|
|
|
|
** 2D objects.
|
|
|
|
**
|
|
|
|
***********************************************************************/
|
|
|
|
|
|
|
|
/*---------------------------------------------------------------------
|
|
|
|
* dist_
|
|
|
|
* Minimum distance from one object to another.
|
|
|
|
*-------------------------------------------------------------------*/
|
|
|
|
|
2014-12-15 16:02:49 +01:00
|
|
|
/*
|
|
|
|
* Distance from a point to a line
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
dist_pl(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *pt = PG_GETARG_POINT_P(0);
|
|
|
|
LINE *line = PG_GETARG_LINE_P(1);
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
PG_RETURN_FLOAT8(line_closept_point(NULL, line, pt));
|
2000-07-30 22:44:02 +02:00
|
|
|
}
|
1997-05-06 09:27:51 +02:00
|
|
|
|
2019-07-14 13:55:01 +02:00
|
|
|
/*
|
|
|
|
* Distance from a line to a point
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
dist_lp(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
LINE *line = PG_GETARG_LINE_P(0);
|
|
|
|
Point *pt = PG_GETARG_POINT_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_FLOAT8(line_closept_point(NULL, line, pt));
|
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2014-12-15 16:02:49 +01:00
|
|
|
/*
|
|
|
|
* Distance from a point to a lseg
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
dist_ps(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
Point *pt = PG_GETARG_POINT_P(0);
|
|
|
|
LSEG *lseg = PG_GETARG_LSEG_P(1);
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
PG_RETURN_FLOAT8(lseg_closept_point(NULL, lseg, pt));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2019-07-14 13:55:01 +02:00
|
|
|
* Distance from a lseg to a point
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
2019-07-14 13:55:01 +02:00
|
|
|
dist_sp(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
LSEG *lseg = PG_GETARG_LSEG_P(0);
|
|
|
|
Point *pt = PG_GETARG_POINT_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_FLOAT8(lseg_closept_point(NULL, lseg, pt));
|
|
|
|
}
|
|
|
|
|
|
|
|
static float8
|
|
|
|
dist_ppath_internal(Point *pt, PATH *path)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
float8 result = 0.0; /* keep compiler quiet */
|
2001-10-13 19:40:24 +02:00
|
|
|
bool have_min = false;
|
2000-07-29 20:46:12 +02:00
|
|
|
float8 tmp;
|
1996-07-09 08:22:35 +02:00
|
|
|
int i;
|
|
|
|
LSEG lseg;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
Assert(path->npts > 0);
|
1997-09-08 04:41:22 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
/*
|
|
|
|
* The distance from a point to a path is the smallest distance from the
|
|
|
|
* point to any of its constituent segments.
|
|
|
|
*/
|
|
|
|
for (i = 0; i < path->npts; i++)
|
|
|
|
{
|
|
|
|
int iprev;
|
2001-10-13 19:40:24 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
if (i > 0)
|
|
|
|
iprev = i - 1;
|
|
|
|
else
|
|
|
|
{
|
|
|
|
if (!path->closed)
|
|
|
|
continue;
|
|
|
|
iprev = path->npts - 1; /* Include the closure segment */
|
|
|
|
}
|
2001-10-13 19:40:24 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
statlseg_construct(&lseg, &path->p[iprev], &path->p[i]);
|
|
|
|
tmp = lseg_closept_point(NULL, &lseg, pt);
|
2018-08-16 19:56:11 +02:00
|
|
|
if (!have_min || float8_lt(tmp, result))
|
2018-07-29 02:02:48 +02:00
|
|
|
{
|
|
|
|
result = tmp;
|
|
|
|
have_min = true;
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
2018-07-29 02:02:48 +02:00
|
|
|
|
2019-07-14 13:55:01 +02:00
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Distance from a point to a path
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
dist_ppath(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
Point *pt = PG_GETARG_POINT_P(0);
|
|
|
|
PATH *path = PG_GETARG_PATH_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_FLOAT8(dist_ppath_internal(pt, path));
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Distance from a path to a point
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
dist_pathp(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
PATH *path = PG_GETARG_PATH_P(0);
|
|
|
|
Point *pt = PG_GETARG_POINT_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_FLOAT8(dist_ppath_internal(pt, path));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2014-12-15 16:02:49 +01:00
|
|
|
/*
|
|
|
|
* Distance from a point to a box
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
dist_pb(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *pt = PG_GETARG_POINT_P(0);
|
|
|
|
BOX *box = PG_GETARG_BOX_P(1);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
PG_RETURN_FLOAT8(box_closept_point(NULL, box, pt));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2019-07-14 13:55:01 +02:00
|
|
|
/*
|
|
|
|
* Distance from a box to a point
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
dist_bp(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
BOX *box = PG_GETARG_BOX_P(0);
|
|
|
|
Point *pt = PG_GETARG_POINT_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_FLOAT8(box_closept_point(NULL, box, pt));
|
|
|
|
}
|
|
|
|
|
2014-12-15 16:02:49 +01:00
|
|
|
/*
|
|
|
|
* Distance from a lseg to a line
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
dist_sl(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LSEG *lseg = PG_GETARG_LSEG_P(0);
|
|
|
|
LINE *line = PG_GETARG_LINE_P(1);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2018-09-26 10:25:24 +02:00
|
|
|
PG_RETURN_FLOAT8(lseg_closept_line(NULL, lseg, line));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2019-07-14 13:55:01 +02:00
|
|
|
/*
|
|
|
|
* Distance from a line to a lseg
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
dist_ls(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
LINE *line = PG_GETARG_LINE_P(0);
|
|
|
|
LSEG *lseg = PG_GETARG_LSEG_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_FLOAT8(lseg_closept_line(NULL, lseg, line));
|
|
|
|
}
|
|
|
|
|
2014-12-15 16:02:49 +01:00
|
|
|
/*
|
|
|
|
* Distance from a lseg to a box
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
dist_sb(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LSEG *lseg = PG_GETARG_LSEG_P(0);
|
|
|
|
BOX *box = PG_GETARG_BOX_P(1);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
PG_RETURN_FLOAT8(box_closept_lseg(NULL, box, lseg));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2019-07-14 13:55:01 +02:00
|
|
|
/*
|
|
|
|
* Distance from a box to a lseg
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
dist_bs(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
BOX *box = PG_GETARG_BOX_P(0);
|
|
|
|
LSEG *lseg = PG_GETARG_LSEG_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_FLOAT8(box_closept_lseg(NULL, box, lseg));
|
|
|
|
}
|
|
|
|
|
|
|
|
static float8
|
|
|
|
dist_cpoly_internal(CIRCLE *circle, POLYGON *poly)
|
1997-07-29 18:08:18 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
float8 result;
|
2014-12-15 16:02:49 +01:00
|
|
|
|
|
|
|
/* calculate distance to center, and subtract radius */
|
2018-08-16 19:56:11 +02:00
|
|
|
result = float8_mi(dist_ppoly_internal(&circle->center, poly),
|
|
|
|
circle->radius);
|
|
|
|
if (result < 0.0)
|
|
|
|
result = 0.0;
|
2014-12-15 16:02:49 +01:00
|
|
|
|
2019-07-14 13:55:01 +02:00
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Distance from a circle to a polygon
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
dist_cpoly(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
CIRCLE *circle = PG_GETARG_CIRCLE_P(0);
|
|
|
|
POLYGON *poly = PG_GETARG_POLYGON_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_FLOAT8(dist_cpoly_internal(circle, poly));
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Distance from a polygon to a circle
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
dist_polyc(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
POLYGON *poly = PG_GETARG_POLYGON_P(0);
|
|
|
|
CIRCLE *circle = PG_GETARG_CIRCLE_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_FLOAT8(dist_cpoly_internal(circle, poly));
|
2014-12-15 16:02:49 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Distance from a point to a polygon
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
dist_ppoly(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
Point *point = PG_GETARG_POINT_P(0);
|
|
|
|
POLYGON *poly = PG_GETARG_POLYGON_P(1);
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
PG_RETURN_FLOAT8(dist_ppoly_internal(point, poly));
|
2014-12-15 16:02:49 +01:00
|
|
|
}
|
|
|
|
|
2015-05-15 13:26:51 +02:00
|
|
|
Datum
|
|
|
|
dist_polyp(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
POLYGON *poly = PG_GETARG_POLYGON_P(0);
|
|
|
|
Point *point = PG_GETARG_POINT_P(1);
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
PG_RETURN_FLOAT8(dist_ppoly_internal(point, poly));
|
2015-05-15 13:26:51 +02:00
|
|
|
}
|
|
|
|
|
2018-08-16 19:56:11 +02:00
|
|
|
static float8
|
2014-12-15 16:02:49 +01:00
|
|
|
dist_ppoly_internal(Point *pt, POLYGON *poly)
|
|
|
|
{
|
|
|
|
float8 result;
|
2000-07-29 20:46:12 +02:00
|
|
|
float8 d;
|
1997-07-29 18:08:18 +02:00
|
|
|
int i;
|
|
|
|
LSEG seg;
|
|
|
|
|
2014-12-15 16:02:49 +01:00
|
|
|
if (point_inside(pt, poly->npts, poly->p) != 0)
|
2014-12-15 20:04:27 +01:00
|
|
|
return 0.0;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1997-07-29 18:08:18 +02:00
|
|
|
/* initialize distance with segment between first and last points */
|
|
|
|
seg.p[0].x = poly->p[0].x;
|
|
|
|
seg.p[0].y = poly->p[0].y;
|
|
|
|
seg.p[1].x = poly->p[poly->npts - 1].x;
|
|
|
|
seg.p[1].y = poly->p[poly->npts - 1].y;
|
2018-07-29 02:02:48 +02:00
|
|
|
result = lseg_closept_point(NULL, &seg, pt);
|
1997-07-29 18:08:18 +02:00
|
|
|
|
|
|
|
/* check distances for other segments */
|
2018-07-29 02:02:48 +02:00
|
|
|
for (i = 0; i < poly->npts - 1; i++)
|
1997-07-29 18:08:18 +02:00
|
|
|
{
|
|
|
|
seg.p[0].x = poly->p[i].x;
|
|
|
|
seg.p[0].y = poly->p[i].y;
|
|
|
|
seg.p[1].x = poly->p[i + 1].x;
|
|
|
|
seg.p[1].y = poly->p[i + 1].y;
|
2018-07-29 02:02:48 +02:00
|
|
|
d = lseg_closept_point(NULL, &seg, pt);
|
2018-08-16 19:56:11 +02:00
|
|
|
if (float8_lt(d, result))
|
2000-07-29 20:46:12 +02:00
|
|
|
result = d;
|
1997-09-05 20:13:45 +02:00
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2014-12-15 16:02:49 +01:00
|
|
|
return result;
|
2000-07-29 20:46:12 +02:00
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*---------------------------------------------------------------------
|
|
|
|
* interpt_
|
|
|
|
* Intersection point of objects.
|
|
|
|
* We choose to ignore the "point" of intersection between
|
|
|
|
* lines and boxes, since there are typically two.
|
|
|
|
*-------------------------------------------------------------------*/
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
/*
|
2018-11-15 16:08:03 +01:00
|
|
|
* Return whether the line segment intersect with the line. If *result is not
|
|
|
|
* NULL, it is set to the intersection point.
|
2018-07-29 02:02:48 +02:00
|
|
|
*/
|
|
|
|
static bool
|
|
|
|
lseg_interpt_line(Point *result, LSEG *lseg, LINE *line)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2018-07-29 02:02:48 +02:00
|
|
|
Point interpt;
|
2000-07-30 22:44:02 +02:00
|
|
|
LINE tmp;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
/*
|
|
|
|
* First, we promote the line segment to a line, because we know how to
|
|
|
|
* find the intersection point of two lines. If they don't have an
|
|
|
|
* intersection point, we are done.
|
|
|
|
*/
|
|
|
|
line_construct(&tmp, &lseg->p[0], lseg_sl(lseg));
|
|
|
|
if (!line_interpt_line(&interpt, &tmp, line))
|
|
|
|
return false;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
/*
|
|
|
|
* Then, we check whether the intersection point is actually on the line
|
|
|
|
* segment.
|
|
|
|
*/
|
|
|
|
if (!lseg_contain_point(lseg, &interpt))
|
|
|
|
return false;
|
2018-11-15 16:08:03 +01:00
|
|
|
if (result != NULL)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* If there is an intersection, then check explicitly for matching
|
|
|
|
* endpoints since there may be rounding effects with annoying LSB
|
|
|
|
* residue.
|
|
|
|
*/
|
|
|
|
if (point_eq_point(&lseg->p[0], &interpt))
|
|
|
|
*result = lseg->p[0];
|
|
|
|
else if (point_eq_point(&lseg->p[1], &interpt))
|
|
|
|
*result = lseg->p[1];
|
|
|
|
else
|
|
|
|
*result = interpt;
|
|
|
|
}
|
2018-07-29 02:02:48 +02:00
|
|
|
|
|
|
|
return true;
|
2000-07-30 22:44:02 +02:00
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
/*---------------------------------------------------------------------
|
|
|
|
* close_
|
|
|
|
* Point of closest proximity between objects.
|
|
|
|
*-------------------------------------------------------------------*/
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
/*
|
2018-11-15 16:08:03 +01:00
|
|
|
* If *result is not NULL, it is set to the intersection point of a
|
|
|
|
* perpendicular of the line through the point. Returns the distance
|
|
|
|
* of those two points.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2018-07-29 02:02:48 +02:00
|
|
|
static float8
|
|
|
|
line_closept_point(Point *result, LINE *line, Point *point)
|
|
|
|
{
|
2018-09-26 10:25:24 +02:00
|
|
|
Point closept;
|
2018-07-29 02:02:48 +02:00
|
|
|
LINE tmp;
|
|
|
|
|
2018-09-26 10:25:24 +02:00
|
|
|
/*
|
|
|
|
* We drop a perpendicular to find the intersection point. Ordinarily we
|
|
|
|
* should always find it, but that can fail in the presence of NaN
|
|
|
|
* coordinates, and perhaps even from simple roundoff issues.
|
|
|
|
*/
|
2018-07-29 02:02:48 +02:00
|
|
|
line_construct(&tmp, point, line_invsl(line));
|
2018-09-26 10:25:24 +02:00
|
|
|
if (!line_interpt_line(&closept, &tmp, line))
|
|
|
|
{
|
|
|
|
if (result != NULL)
|
|
|
|
*result = *point;
|
2018-07-29 23:08:00 +02:00
|
|
|
|
2018-09-26 10:25:24 +02:00
|
|
|
return get_float8_nan();
|
|
|
|
}
|
2018-07-29 02:02:48 +02:00
|
|
|
|
|
|
|
if (result != NULL)
|
|
|
|
*result = closept;
|
|
|
|
|
|
|
|
return point_dt(&closept, point);
|
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
close_pl(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *pt = PG_GETARG_POINT_P(0);
|
|
|
|
LINE *line = PG_GETARG_LINE_P(1);
|
1996-07-09 08:22:35 +02:00
|
|
|
Point *result;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
result = (Point *) palloc(sizeof(Point));
|
|
|
|
|
2018-08-16 19:56:11 +02:00
|
|
|
if (isnan(line_closept_point(result, line, pt)))
|
|
|
|
PG_RETURN_NULL();
|
2013-10-09 07:09:18 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_POINT_P(result);
|
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
/*
|
1998-02-03 16:55:58 +01:00
|
|
|
* Closest point on line segment to specified point.
|
|
|
|
*
|
2018-11-15 16:08:03 +01:00
|
|
|
* If *result is not NULL, set it to the closest point on the line segment
|
|
|
|
* to the point. Returns the distance of the two points.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2018-07-29 02:02:48 +02:00
|
|
|
static float8
|
|
|
|
lseg_closept_point(Point *result, LSEG *lseg, Point *pt)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2018-07-29 02:02:48 +02:00
|
|
|
Point closept;
|
|
|
|
LINE tmp;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1998-05-10 00:39:55 +02:00
|
|
|
/*
|
2018-07-29 02:02:48 +02:00
|
|
|
* To find the closest point, we draw a perpendicular line from the point
|
|
|
|
* to the line segment.
|
1998-05-10 00:39:55 +02:00
|
|
|
*/
|
2018-07-29 02:02:48 +02:00
|
|
|
line_construct(&tmp, pt, point_invsl(&lseg->p[0], &lseg->p[1]));
|
|
|
|
lseg_closept_line(&closept, lseg, &tmp);
|
1998-05-10 00:39:55 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
if (result != NULL)
|
|
|
|
*result = closept;
|
1998-05-10 00:39:55 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
return point_dt(&closept, pt);
|
|
|
|
}
|
2016-07-16 20:42:37 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
Datum
|
|
|
|
close_ps(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
Point *pt = PG_GETARG_POINT_P(0);
|
|
|
|
LSEG *lseg = PG_GETARG_LSEG_P(1);
|
|
|
|
Point *result;
|
|
|
|
|
|
|
|
result = (Point *) palloc(sizeof(Point));
|
|
|
|
|
|
|
|
if (isnan(lseg_closept_point(result, lseg, pt)))
|
2016-07-16 20:42:37 +02:00
|
|
|
PG_RETURN_NULL();
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_POINT_P(result);
|
|
|
|
}
|
1998-02-03 16:55:58 +01:00
|
|
|
|
1998-08-15 08:45:10 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
/*
|
|
|
|
* Closest point on line segment to line segment
|
1998-02-03 16:55:58 +01:00
|
|
|
*/
|
2018-07-29 02:02:48 +02:00
|
|
|
static float8
|
2018-11-15 16:08:03 +01:00
|
|
|
lseg_closept_lseg(Point *result, LSEG *on_lseg, LSEG *to_lseg)
|
1998-02-03 16:55:58 +01:00
|
|
|
{
|
|
|
|
Point point;
|
2018-08-16 19:56:11 +02:00
|
|
|
float8 dist,
|
|
|
|
d;
|
1998-02-03 16:55:58 +01:00
|
|
|
|
2018-09-26 10:25:24 +02:00
|
|
|
/* First, we handle the case when the line segments are intersecting. */
|
2018-11-15 16:08:03 +01:00
|
|
|
if (lseg_interpt_lseg(result, on_lseg, to_lseg))
|
2018-09-26 10:25:24 +02:00
|
|
|
return 0.0;
|
1998-02-03 16:55:58 +01:00
|
|
|
|
2018-09-26 10:25:24 +02:00
|
|
|
/*
|
|
|
|
* Then, we find the closest points from the endpoints of the second line
|
|
|
|
* segment, and keep the closest one.
|
|
|
|
*/
|
2018-11-15 16:08:03 +01:00
|
|
|
dist = lseg_closept_point(result, on_lseg, &to_lseg->p[0]);
|
|
|
|
d = lseg_closept_point(&point, on_lseg, &to_lseg->p[1]);
|
2018-08-16 19:56:11 +02:00
|
|
|
if (float8_lt(d, dist))
|
1998-02-03 16:55:58 +01:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
dist = d;
|
2018-07-29 02:02:48 +02:00
|
|
|
if (result != NULL)
|
2018-09-26 10:25:24 +02:00
|
|
|
*result = point;
|
1998-02-03 16:55:58 +01:00
|
|
|
}
|
|
|
|
|
2018-09-26 10:25:24 +02:00
|
|
|
/* The closest point can still be one of the endpoints, so we test them. */
|
2018-11-15 16:08:03 +01:00
|
|
|
d = lseg_closept_point(NULL, to_lseg, &on_lseg->p[0]);
|
2018-08-16 19:56:11 +02:00
|
|
|
if (float8_lt(d, dist))
|
2018-09-26 10:25:24 +02:00
|
|
|
{
|
2018-07-29 02:02:48 +02:00
|
|
|
dist = d;
|
2018-09-26 10:25:24 +02:00
|
|
|
if (result != NULL)
|
2018-11-15 16:08:03 +01:00
|
|
|
*result = on_lseg->p[0];
|
2018-09-26 10:25:24 +02:00
|
|
|
}
|
2018-11-15 16:08:03 +01:00
|
|
|
d = lseg_closept_point(NULL, to_lseg, &on_lseg->p[1]);
|
2018-09-26 10:25:24 +02:00
|
|
|
if (float8_lt(d, dist))
|
|
|
|
{
|
|
|
|
dist = d;
|
|
|
|
if (result != NULL)
|
2018-11-15 16:08:03 +01:00
|
|
|
*result = on_lseg->p[1];
|
2018-09-26 10:25:24 +02:00
|
|
|
}
|
2018-07-29 02:02:48 +02:00
|
|
|
|
|
|
|
return dist;
|
|
|
|
}
|
|
|
|
|
|
|
|
Datum
|
|
|
|
close_lseg(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
LSEG *l1 = PG_GETARG_LSEG_P(0);
|
|
|
|
LSEG *l2 = PG_GETARG_LSEG_P(1);
|
|
|
|
Point *result;
|
|
|
|
|
2018-09-26 10:25:24 +02:00
|
|
|
if (lseg_sl(l1) == lseg_sl(l2))
|
|
|
|
PG_RETURN_NULL();
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
result = (Point *) palloc(sizeof(Point));
|
|
|
|
|
2018-08-16 19:56:11 +02:00
|
|
|
if (isnan(lseg_closept_lseg(result, l2, l1)))
|
|
|
|
PG_RETURN_NULL();
|
1998-02-03 16:55:58 +01:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_POINT_P(result);
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
|
|
|
|
/*
|
1998-02-03 16:55:58 +01:00
|
|
|
* Closest point on or in box to specified point.
|
2018-07-29 02:02:48 +02:00
|
|
|
*
|
2018-11-15 16:08:03 +01:00
|
|
|
* If *result is not NULL, set it to the closest point on the box to the
|
|
|
|
* given point, and return the distance of the two points.
|
1998-02-03 16:55:58 +01:00
|
|
|
*/
|
2018-07-29 02:02:48 +02:00
|
|
|
static float8
|
|
|
|
box_closept_point(Point *result, BOX *box, Point *pt)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2018-08-16 19:56:11 +02:00
|
|
|
float8 dist,
|
|
|
|
d;
|
2018-07-29 02:02:48 +02:00
|
|
|
Point point,
|
|
|
|
closept;
|
2018-08-16 19:56:11 +02:00
|
|
|
LSEG lseg;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
if (box_contain_point(box, pt))
|
|
|
|
{
|
|
|
|
if (result != NULL)
|
|
|
|
*result = *pt;
|
|
|
|
|
|
|
|
return 0.0;
|
|
|
|
}
|
1998-02-03 16:55:58 +01:00
|
|
|
|
|
|
|
/* pairwise check lseg distances */
|
|
|
|
point.x = box->low.x;
|
|
|
|
point.y = box->high.y;
|
|
|
|
statlseg_construct(&lseg, &box->low, &point);
|
2018-07-29 02:02:48 +02:00
|
|
|
dist = lseg_closept_point(result, &lseg, pt);
|
1998-02-03 16:55:58 +01:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
statlseg_construct(&lseg, &box->high, &point);
|
|
|
|
d = lseg_closept_point(&closept, &lseg, pt);
|
2018-08-16 19:56:11 +02:00
|
|
|
if (float8_lt(d, dist))
|
1998-02-03 16:55:58 +01:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
dist = d;
|
2018-07-29 02:02:48 +02:00
|
|
|
if (result != NULL)
|
|
|
|
*result = closept;
|
1998-02-03 16:55:58 +01:00
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
1998-02-03 16:55:58 +01:00
|
|
|
point.x = box->high.x;
|
|
|
|
point.y = box->low.y;
|
2018-07-29 02:02:48 +02:00
|
|
|
statlseg_construct(&lseg, &box->low, &point);
|
|
|
|
d = lseg_closept_point(&closept, &lseg, pt);
|
2018-08-16 19:56:11 +02:00
|
|
|
if (float8_lt(d, dist))
|
1998-02-03 16:55:58 +01:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
dist = d;
|
2018-07-29 02:02:48 +02:00
|
|
|
if (result != NULL)
|
|
|
|
*result = closept;
|
1998-02-03 16:55:58 +01:00
|
|
|
}
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
statlseg_construct(&lseg, &box->high, &point);
|
|
|
|
d = lseg_closept_point(&closept, &lseg, pt);
|
2018-08-16 19:56:11 +02:00
|
|
|
if (float8_lt(d, dist))
|
1998-02-03 16:55:58 +01:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
dist = d;
|
2018-07-29 02:02:48 +02:00
|
|
|
if (result != NULL)
|
|
|
|
*result = closept;
|
1998-02-03 16:55:58 +01:00
|
|
|
}
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
return dist;
|
2000-07-30 22:44:02 +02:00
|
|
|
}
|
1998-02-03 16:55:58 +01:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
Datum
|
|
|
|
close_pb(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
Point *pt = PG_GETARG_POINT_P(0);
|
|
|
|
BOX *box = PG_GETARG_BOX_P(1);
|
|
|
|
Point *result;
|
|
|
|
|
|
|
|
result = (Point *) palloc(sizeof(Point));
|
|
|
|
|
2018-08-16 19:56:11 +02:00
|
|
|
if (isnan(box_closept_point(result, box, pt)))
|
|
|
|
PG_RETURN_NULL();
|
2018-07-29 02:02:48 +02:00
|
|
|
|
|
|
|
PG_RETURN_POINT_P(result);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
1998-02-03 16:55:58 +01:00
|
|
|
* Closest point on line segment to line.
|
2018-07-29 02:02:48 +02:00
|
|
|
*
|
2018-11-15 16:08:03 +01:00
|
|
|
* Return the distance between the line and the closest point of the line
|
|
|
|
* segment to the line. If *result is not NULL, set it to that point.
|
2018-07-29 02:02:48 +02:00
|
|
|
*
|
|
|
|
* NOTE: When the lines are parallel, endpoints of one of the line segment
|
2018-11-15 16:08:03 +01:00
|
|
|
* are FPeq(), in presence of NaN or Infinite coordinates, or perhaps =
|
2018-07-29 02:02:48 +02:00
|
|
|
* even because of simple roundoff issues, there may not be a single closest
|
|
|
|
* point. We are likely to set the result to the second endpoint in these
|
|
|
|
* cases.
|
1998-02-03 16:55:58 +01:00
|
|
|
*/
|
2018-07-29 02:02:48 +02:00
|
|
|
static float8
|
|
|
|
lseg_closept_line(Point *result, LSEG *lseg, LINE *line)
|
|
|
|
{
|
|
|
|
float8 dist1,
|
|
|
|
dist2;
|
|
|
|
|
|
|
|
if (lseg_interpt_line(result, lseg, line))
|
|
|
|
return 0.0;
|
|
|
|
|
|
|
|
dist1 = line_closept_point(NULL, line, &lseg->p[0]);
|
|
|
|
dist2 = line_closept_point(NULL, line, &lseg->p[1]);
|
|
|
|
|
|
|
|
if (dist1 < dist2)
|
|
|
|
{
|
|
|
|
if (result != NULL)
|
|
|
|
*result = lseg->p[0];
|
|
|
|
|
|
|
|
return dist1;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
if (result != NULL)
|
|
|
|
*result = lseg->p[1];
|
|
|
|
|
|
|
|
return dist2;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
close_ls(PG_FUNCTION_ARGS)
|
1998-02-03 16:55:58 +01:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LINE *line = PG_GETARG_LINE_P(0);
|
|
|
|
LSEG *lseg = PG_GETARG_LSEG_P(1);
|
1998-02-03 16:55:58 +01:00
|
|
|
Point *result;
|
|
|
|
|
2018-09-26 10:25:24 +02:00
|
|
|
if (lseg_sl(lseg) == line_sl(line))
|
|
|
|
PG_RETURN_NULL();
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
result = (Point *) palloc(sizeof(Point));
|
1998-02-03 16:55:58 +01:00
|
|
|
|
2018-08-16 19:56:11 +02:00
|
|
|
if (isnan(lseg_closept_line(result, lseg, line)))
|
|
|
|
PG_RETURN_NULL();
|
1998-02-03 16:55:58 +01:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_POINT_P(result);
|
|
|
|
}
|
1998-02-03 16:55:58 +01:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
|
|
|
|
/*
|
1998-02-03 16:55:58 +01:00
|
|
|
* Closest point on or in box to line segment.
|
2018-07-29 02:02:48 +02:00
|
|
|
*
|
2018-11-15 16:08:03 +01:00
|
|
|
* Returns the distance between the closest point on or in the box to
|
|
|
|
* the line segment. If *result is not NULL, it is set to that point.
|
1998-02-03 16:55:58 +01:00
|
|
|
*/
|
2018-07-29 02:02:48 +02:00
|
|
|
static float8
|
|
|
|
box_closept_lseg(Point *result, BOX *box, LSEG *lseg)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2018-08-16 19:56:11 +02:00
|
|
|
float8 dist,
|
|
|
|
d;
|
2018-07-29 02:02:48 +02:00
|
|
|
Point point,
|
|
|
|
closept;
|
|
|
|
LSEG bseg;
|
1998-02-03 16:55:58 +01:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
if (box_interpt_lseg(result, box, lseg))
|
|
|
|
return 0.0;
|
1998-02-03 16:55:58 +01:00
|
|
|
|
|
|
|
/* pairwise check lseg distances */
|
|
|
|
point.x = box->low.x;
|
|
|
|
point.y = box->high.y;
|
|
|
|
statlseg_construct(&bseg, &box->low, &point);
|
2018-07-29 02:02:48 +02:00
|
|
|
dist = lseg_closept_lseg(result, &bseg, lseg);
|
1998-02-03 16:55:58 +01:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
statlseg_construct(&bseg, &box->high, &point);
|
|
|
|
d = lseg_closept_lseg(&closept, &bseg, lseg);
|
2018-08-16 19:56:11 +02:00
|
|
|
if (float8_lt(d, dist))
|
1998-02-03 16:55:58 +01:00
|
|
|
{
|
|
|
|
dist = d;
|
2018-07-29 02:02:48 +02:00
|
|
|
if (result != NULL)
|
|
|
|
*result = closept;
|
1998-02-03 16:55:58 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
point.x = box->high.x;
|
|
|
|
point.y = box->low.y;
|
2018-07-29 02:02:48 +02:00
|
|
|
statlseg_construct(&bseg, &box->low, &point);
|
|
|
|
d = lseg_closept_lseg(&closept, &bseg, lseg);
|
2018-08-16 19:56:11 +02:00
|
|
|
if (float8_lt(d, dist))
|
1998-02-03 16:55:58 +01:00
|
|
|
{
|
|
|
|
dist = d;
|
2018-07-29 02:02:48 +02:00
|
|
|
if (result != NULL)
|
|
|
|
*result = closept;
|
1998-02-03 16:55:58 +01:00
|
|
|
}
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
statlseg_construct(&bseg, &box->high, &point);
|
|
|
|
d = lseg_closept_lseg(&closept, &bseg, lseg);
|
2018-08-16 19:56:11 +02:00
|
|
|
if (float8_lt(d, dist))
|
1998-02-03 16:55:58 +01:00
|
|
|
{
|
|
|
|
dist = d;
|
2018-07-29 02:02:48 +02:00
|
|
|
if (result != NULL)
|
|
|
|
*result = closept;
|
1998-02-03 16:55:58 +01:00
|
|
|
}
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
return dist;
|
2000-07-30 22:44:02 +02:00
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
Datum
|
|
|
|
close_sb(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
LSEG *lseg = PG_GETARG_LSEG_P(0);
|
|
|
|
BOX *box = PG_GETARG_BOX_P(1);
|
|
|
|
Point *result;
|
|
|
|
|
|
|
|
result = (Point *) palloc(sizeof(Point));
|
|
|
|
|
2018-08-16 19:56:11 +02:00
|
|
|
if (isnan(box_closept_lseg(result, box, lseg)))
|
|
|
|
PG_RETURN_NULL();
|
2018-07-29 02:02:48 +02:00
|
|
|
|
|
|
|
PG_RETURN_POINT_P(result);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*---------------------------------------------------------------------
|
|
|
|
* on_
|
|
|
|
* Whether one object lies completely within another.
|
|
|
|
*-------------------------------------------------------------------*/
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
/*
|
1996-07-09 08:22:35 +02:00
|
|
|
* Does the point satisfy the equation?
|
|
|
|
*/
|
2018-07-29 02:02:48 +02:00
|
|
|
static bool
|
|
|
|
line_contain_point(LINE *line, Point *point)
|
|
|
|
{
|
2018-08-16 19:56:11 +02:00
|
|
|
return FPzero(float8_pl(float8_pl(float8_mul(line->A, point->x),
|
|
|
|
float8_mul(line->B, point->y)),
|
|
|
|
line->C));
|
2018-07-29 02:02:48 +02:00
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
on_pl(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *pt = PG_GETARG_POINT_P(0);
|
|
|
|
LINE *line = PG_GETARG_LINE_P(1);
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
PG_RETURN_BOOL(line_contain_point(line, pt));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
/*
|
1996-07-09 08:22:35 +02:00
|
|
|
* Determine colinearity by detecting a triangle inequality.
|
1997-07-29 18:08:18 +02:00
|
|
|
* This algorithm seems to behave nicely even with lsb residues - tgl 1997-07-09
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2018-07-29 02:02:48 +02:00
|
|
|
static bool
|
|
|
|
lseg_contain_point(LSEG *lseg, Point *pt)
|
|
|
|
{
|
|
|
|
return FPeq(point_dt(pt, &lseg->p[0]) +
|
|
|
|
point_dt(pt, &lseg->p[1]),
|
|
|
|
point_dt(&lseg->p[0], &lseg->p[1]));
|
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
on_ps(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *pt = PG_GETARG_POINT_P(0);
|
|
|
|
LSEG *lseg = PG_GETARG_LSEG_P(1);
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
PG_RETURN_BOOL(lseg_contain_point(lseg, pt));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Check whether the point is in the box or on its border
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
static bool
|
2018-07-29 02:02:48 +02:00
|
|
|
box_contain_point(BOX *box, Point *point)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2018-07-29 02:02:48 +02:00
|
|
|
return box->high.x >= point->x && box->low.x <= point->x &&
|
|
|
|
box->high.y >= point->y && box->low.y <= point->y;
|
2000-07-30 22:44:02 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
Datum
|
|
|
|
on_pb(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
Point *pt = PG_GETARG_POINT_P(0);
|
|
|
|
BOX *box = PG_GETARG_BOX_P(1);
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
PG_RETURN_BOOL(box_contain_point(box, pt));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2010-01-14 17:31:09 +01:00
|
|
|
Datum
|
|
|
|
box_contain_pt(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
BOX *box = PG_GETARG_BOX_P(0);
|
|
|
|
Point *pt = PG_GETARG_POINT_P(1);
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
PG_RETURN_BOOL(box_contain_point(box, pt));
|
2010-01-14 17:31:09 +01:00
|
|
|
}
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/* on_ppath -
|
|
|
|
* Whether a point lies within (on) a polyline.
|
|
|
|
* If open, we have to (groan) check each segment.
|
1997-07-29 18:08:18 +02:00
|
|
|
* (uses same algorithm as for point intersecting segment - tgl 1997-07-09)
|
1996-07-09 08:22:35 +02:00
|
|
|
* If closed, we use the old O(n) ray method for point-in-polygon.
|
|
|
|
* The ray is horizontal, from pt out to the right.
|
|
|
|
* Each segment that crosses the ray counts as an
|
|
|
|
* intersection; note that an endpoint or edge may touch
|
|
|
|
* but not cross.
|
|
|
|
* (we can do p-in-p in lg(n), but it takes preprocessing)
|
|
|
|
*/
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
on_ppath(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
Point *pt = PG_GETARG_POINT_P(0);
|
|
|
|
PATH *path = PG_GETARG_PATH_P(1);
|
1997-07-29 18:08:18 +02:00
|
|
|
int i,
|
|
|
|
n;
|
2018-08-16 19:56:11 +02:00
|
|
|
float8 a,
|
1997-07-29 18:08:18 +02:00
|
|
|
b;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1998-10-29 19:11:28 +01:00
|
|
|
/*-- OPEN --*/
|
1996-07-09 08:22:35 +02:00
|
|
|
if (!path->closed)
|
1998-10-29 19:11:28 +01:00
|
|
|
{
|
1996-07-09 08:22:35 +02:00
|
|
|
n = path->npts - 1;
|
|
|
|
a = point_dt(pt, &path->p[0]);
|
|
|
|
for (i = 0; i < n; i++)
|
|
|
|
{
|
|
|
|
b = point_dt(pt, &path->p[i + 1]);
|
2018-08-16 19:56:11 +02:00
|
|
|
if (FPeq(float8_pl(a, b), point_dt(&path->p[i], &path->p[i + 1])))
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_BOOL(true);
|
1996-07-09 08:22:35 +02:00
|
|
|
a = b;
|
|
|
|
}
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_BOOL(false);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1998-10-29 19:11:28 +01:00
|
|
|
/*-- CLOSED --*/
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_BOOL(point_inside(pt, path->npts, path->p) != 0);
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Check whether the line segment is on the line or close enough
|
|
|
|
*
|
|
|
|
* It is, if both of its points are on the line or close enough.
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
on_sl(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LSEG *lseg = PG_GETARG_LSEG_P(0);
|
|
|
|
LINE *line = PG_GETARG_LINE_P(1);
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
PG_RETURN_BOOL(line_contain_point(line, &lseg->p[0]) &&
|
|
|
|
line_contain_point(line, &lseg->p[1]));
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check whether the line segment is in the box or on its border
|
|
|
|
*
|
|
|
|
* It is, if both of its points are in the box or on its border.
|
|
|
|
*/
|
|
|
|
static bool
|
|
|
|
box_contain_lseg(BOX *box, LSEG *lseg)
|
|
|
|
{
|
|
|
|
return box_contain_point(box, &lseg->p[0]) &&
|
|
|
|
box_contain_point(box, &lseg->p[1]);
|
2000-07-30 22:44:02 +02:00
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
on_sb(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LSEG *lseg = PG_GETARG_LSEG_P(0);
|
|
|
|
BOX *box = PG_GETARG_BOX_P(1);
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
PG_RETURN_BOOL(box_contain_lseg(box, lseg));
|
2000-07-30 22:44:02 +02:00
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
/*---------------------------------------------------------------------
|
|
|
|
* inter_
|
|
|
|
* Whether one object intersects another.
|
|
|
|
*-------------------------------------------------------------------*/
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
inter_sl(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LSEG *lseg = PG_GETARG_LSEG_P(0);
|
|
|
|
LINE *line = PG_GETARG_LINE_P(1);
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
PG_RETURN_BOOL(lseg_interpt_line(NULL, lseg, line));
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
|
|
|
|
/*
|
1998-02-03 16:55:58 +01:00
|
|
|
* Do line segment and box intersect?
|
|
|
|
*
|
|
|
|
* Segment completely inside box counts as intersection.
|
|
|
|
* If you want only segments crossing box boundaries,
|
|
|
|
* try converting box to path first.
|
|
|
|
*
|
2018-07-29 02:02:48 +02:00
|
|
|
* This function also sets the *result to the closest point on the line
|
|
|
|
* segment to the center of the box when they overlap and the result is
|
|
|
|
* not NULL. It is somewhat arbitrary, but maybe the best we can do as
|
|
|
|
* there are typically two points they intersect.
|
|
|
|
*
|
1998-02-03 16:55:58 +01:00
|
|
|
* Optimize for non-intersection by checking for box intersection first.
|
|
|
|
* - thomas 1998-01-30
|
|
|
|
*/
|
2018-07-29 02:02:48 +02:00
|
|
|
static bool
|
|
|
|
box_interpt_lseg(Point *result, BOX *box, LSEG *lseg)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
1998-02-03 16:55:58 +01:00
|
|
|
BOX lbox;
|
|
|
|
LSEG bseg;
|
2000-07-30 22:44:02 +02:00
|
|
|
Point point;
|
1998-02-03 16:55:58 +01:00
|
|
|
|
2018-08-16 19:56:11 +02:00
|
|
|
lbox.low.x = float8_min(lseg->p[0].x, lseg->p[1].x);
|
|
|
|
lbox.low.y = float8_min(lseg->p[0].y, lseg->p[1].y);
|
|
|
|
lbox.high.x = float8_max(lseg->p[0].x, lseg->p[1].x);
|
|
|
|
lbox.high.y = float8_max(lseg->p[0].y, lseg->p[1].y);
|
1998-02-03 16:55:58 +01:00
|
|
|
|
|
|
|
/* nothing close to overlap? then not going to intersect */
|
2000-07-30 22:44:02 +02:00
|
|
|
if (!box_ov(&lbox, box))
|
2018-07-29 02:02:48 +02:00
|
|
|
return false;
|
|
|
|
|
|
|
|
if (result != NULL)
|
|
|
|
{
|
|
|
|
box_cn(&point, box);
|
|
|
|
lseg_closept_point(result, lseg, &point);
|
|
|
|
}
|
1998-02-03 16:55:58 +01:00
|
|
|
|
|
|
|
/* an endpoint of segment is inside box? then clearly intersects */
|
2018-07-29 02:02:48 +02:00
|
|
|
if (box_contain_point(box, &lseg->p[0]) ||
|
|
|
|
box_contain_point(box, &lseg->p[1]))
|
|
|
|
return true;
|
1998-02-03 16:55:58 +01:00
|
|
|
|
|
|
|
/* pairwise check lseg intersections */
|
|
|
|
point.x = box->low.x;
|
|
|
|
point.y = box->high.y;
|
|
|
|
statlseg_construct(&bseg, &box->low, &point);
|
2018-07-29 02:02:48 +02:00
|
|
|
if (lseg_interpt_lseg(NULL, &bseg, lseg))
|
|
|
|
return true;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
1998-02-03 16:55:58 +01:00
|
|
|
statlseg_construct(&bseg, &box->high, &point);
|
2018-07-29 02:02:48 +02:00
|
|
|
if (lseg_interpt_lseg(NULL, &bseg, lseg))
|
|
|
|
return true;
|
1998-02-03 16:55:58 +01:00
|
|
|
|
|
|
|
point.x = box->high.x;
|
|
|
|
point.y = box->low.y;
|
|
|
|
statlseg_construct(&bseg, &box->low, &point);
|
2018-07-29 02:02:48 +02:00
|
|
|
if (lseg_interpt_lseg(NULL, &bseg, lseg))
|
|
|
|
return true;
|
1998-02-03 16:55:58 +01:00
|
|
|
|
|
|
|
statlseg_construct(&bseg, &box->high, &point);
|
2018-07-29 02:02:48 +02:00
|
|
|
if (lseg_interpt_lseg(NULL, &bseg, lseg))
|
|
|
|
return true;
|
1998-02-03 16:55:58 +01:00
|
|
|
|
|
|
|
/* if we dropped through, no two segs intersected */
|
2018-07-29 02:02:48 +02:00
|
|
|
return false;
|
2000-07-30 22:44:02 +02:00
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
Datum
|
|
|
|
inter_sb(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
LSEG *lseg = PG_GETARG_LSEG_P(0);
|
|
|
|
BOX *box = PG_GETARG_BOX_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(box_interpt_lseg(NULL, box, lseg));
|
|
|
|
}
|
|
|
|
|
|
|
|
|
1998-02-03 16:55:58 +01:00
|
|
|
/* inter_lb()
|
|
|
|
* Do line and box intersect?
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
inter_lb(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LINE *line = PG_GETARG_LINE_P(0);
|
|
|
|
BOX *box = PG_GETARG_BOX_P(1);
|
1998-02-03 16:55:58 +01:00
|
|
|
LSEG bseg;
|
|
|
|
Point p1,
|
|
|
|
p2;
|
|
|
|
|
|
|
|
/* pairwise check lseg intersections */
|
|
|
|
p1.x = box->low.x;
|
|
|
|
p1.y = box->low.y;
|
|
|
|
p2.x = box->low.x;
|
|
|
|
p2.y = box->high.y;
|
|
|
|
statlseg_construct(&bseg, &p1, &p2);
|
2018-07-29 02:02:48 +02:00
|
|
|
if (lseg_interpt_line(NULL, &bseg, line))
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOOL(true);
|
1998-02-03 16:55:58 +01:00
|
|
|
p1.x = box->high.x;
|
|
|
|
p1.y = box->high.y;
|
|
|
|
statlseg_construct(&bseg, &p1, &p2);
|
2018-07-29 02:02:48 +02:00
|
|
|
if (lseg_interpt_line(NULL, &bseg, line))
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOOL(true);
|
1998-02-03 16:55:58 +01:00
|
|
|
p2.x = box->high.x;
|
|
|
|
p2.y = box->low.y;
|
|
|
|
statlseg_construct(&bseg, &p1, &p2);
|
2018-07-29 02:02:48 +02:00
|
|
|
if (lseg_interpt_line(NULL, &bseg, line))
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOOL(true);
|
1998-02-03 16:55:58 +01:00
|
|
|
p1.x = box->low.x;
|
|
|
|
p1.y = box->low.y;
|
|
|
|
statlseg_construct(&bseg, &p1, &p2);
|
2018-07-29 02:02:48 +02:00
|
|
|
if (lseg_interpt_line(NULL, &bseg, line))
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOOL(true);
|
1998-02-03 16:55:58 +01:00
|
|
|
|
|
|
|
/* if we dropped through, no intersection */
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOOL(false);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*------------------------------------------------------------------
|
|
|
|
* The following routines define a data type and operator class for
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
* POLYGONS .... Part of which (the polygon's bounding box) is built on
|
1996-07-09 08:22:35 +02:00
|
|
|
* top of the BOX data type.
|
|
|
|
*
|
|
|
|
* make_bound_box - create the bounding box for the input polygon
|
|
|
|
*------------------------------------------------------------------*/
|
|
|
|
|
|
|
|
/*---------------------------------------------------------------------
|
|
|
|
* Make the smallest bounding box for the given polygon.
|
|
|
|
*---------------------------------------------------------------------*/
|
1997-08-19 23:40:56 +02:00
|
|
|
static void
|
|
|
|
make_bound_box(POLYGON *poly)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
int i;
|
2018-08-16 19:56:11 +02:00
|
|
|
float8 x1,
|
1996-07-09 08:22:35 +02:00
|
|
|
y1,
|
|
|
|
x2,
|
|
|
|
y2;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
Assert(poly->npts > 0);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
x1 = x2 = poly->p[0].x;
|
|
|
|
y2 = y1 = poly->p[0].y;
|
|
|
|
for (i = 1; i < poly->npts; i++)
|
|
|
|
{
|
2018-08-16 19:56:11 +02:00
|
|
|
if (float8_lt(poly->p[i].x, x1))
|
2018-07-29 02:02:48 +02:00
|
|
|
x1 = poly->p[i].x;
|
2018-08-16 19:56:11 +02:00
|
|
|
if (float8_gt(poly->p[i].x, x2))
|
2018-07-29 02:02:48 +02:00
|
|
|
x2 = poly->p[i].x;
|
2018-08-16 19:56:11 +02:00
|
|
|
if (float8_lt(poly->p[i].y, y1))
|
2018-07-29 02:02:48 +02:00
|
|
|
y1 = poly->p[i].y;
|
2018-08-16 19:56:11 +02:00
|
|
|
if (float8_gt(poly->p[i].y, y2))
|
2018-07-29 02:02:48 +02:00
|
|
|
y2 = poly->p[i].y;
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
2018-07-29 02:02:48 +02:00
|
|
|
|
|
|
|
poly->boundbox.low.x = x1;
|
|
|
|
poly->boundbox.high.x = x2;
|
|
|
|
poly->boundbox.low.y = y1;
|
|
|
|
poly->boundbox.high.y = y2;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*------------------------------------------------------------------
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
* poly_in - read in the polygon from a string specification
|
|
|
|
*
|
|
|
|
* External format:
|
|
|
|
* "((x0,y0),...,(xn,yn))"
|
|
|
|
* "x0,y0,...,xn,yn"
|
|
|
|
* also supports the older style "(x1,...,xn,y1,...yn)"
|
1996-07-09 08:22:35 +02:00
|
|
|
*------------------------------------------------------------------*/
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
poly_in(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
char *str = PG_GETARG_CSTRING(0);
|
1996-07-09 08:22:35 +02:00
|
|
|
POLYGON *poly;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
int npts;
|
|
|
|
int size;
|
2014-02-17 15:33:31 +01:00
|
|
|
int base_size;
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
bool isopen;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
|
|
|
if ((npts = pair_count(str, ',')) <= 0)
|
2003-07-27 06:53:12 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
errmsg("invalid input syntax for type %s: \"%s\"",
|
|
|
|
"polygon", str)));
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2014-02-17 15:33:31 +01:00
|
|
|
base_size = sizeof(poly->p[0]) * npts;
|
2015-02-20 06:11:42 +01:00
|
|
|
size = offsetof(POLYGON, p) + base_size;
|
2014-02-17 15:33:31 +01:00
|
|
|
|
|
|
|
/* Check for integer overflow */
|
|
|
|
if (base_size / npts != sizeof(poly->p[0]) || size <= base_size)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
|
|
|
|
errmsg("too many points requested")));
|
|
|
|
|
2002-11-13 01:39:48 +01:00
|
|
|
poly = (POLYGON *) palloc0(size); /* zero any holes */
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2007-02-28 00:48:10 +01:00
|
|
|
SET_VARSIZE(poly, size);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
poly->npts = npts;
|
|
|
|
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
path_decode(str, false, npts, &(poly->p[0]), &isopen, NULL, "polygon", str);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
make_bound_box(poly);
|
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_POLYGON_P(poly);
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
/*---------------------------------------------------------------
|
|
|
|
* poly_out - convert internal POLYGON representation to the
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
* character string format "((f8,f8),...,(f8,f8))"
|
1996-07-09 08:22:35 +02:00
|
|
|
*---------------------------------------------------------------*/
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
poly_out(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
POLYGON *poly = PG_GETARG_POLYGON_P(0);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2013-07-09 04:42:39 +02:00
|
|
|
PG_RETURN_CSTRING(path_encode(PATH_CLOSED, poly->npts, poly->p));
|
2000-07-29 20:46:12 +02:00
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2003-05-13 20:03:08 +02:00
|
|
|
/*
|
|
|
|
* poly_recv - converts external binary format to polygon
|
|
|
|
*
|
|
|
|
* External representation is int32 number of points, and the points.
|
|
|
|
* We recompute the bounding box on read, instead of trusting it to
|
|
|
|
* be valid. (Checking it would take just as long, so may as well
|
|
|
|
* omit it from external representation.)
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
poly_recv(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
StringInfo buf = (StringInfo) PG_GETARG_POINTER(0);
|
|
|
|
POLYGON *poly;
|
|
|
|
int32 npts;
|
|
|
|
int32 i;
|
|
|
|
int size;
|
|
|
|
|
|
|
|
npts = pq_getmsgint(buf, sizeof(int32));
|
2015-02-20 06:11:42 +01:00
|
|
|
if (npts <= 0 || npts >= (int32) ((INT_MAX - offsetof(POLYGON, p)) / sizeof(Point)))
|
2003-07-27 06:53:12 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_BINARY_REPRESENTATION),
|
2003-09-29 02:05:25 +02:00
|
|
|
errmsg("invalid number of points in external \"polygon\" value")));
|
2003-05-13 20:03:08 +02:00
|
|
|
|
2015-02-20 06:11:42 +01:00
|
|
|
size = offsetof(POLYGON, p) + sizeof(poly->p[0]) * npts;
|
2003-05-13 20:03:08 +02:00
|
|
|
poly = (POLYGON *) palloc0(size); /* zero any holes */
|
|
|
|
|
2007-02-28 00:48:10 +01:00
|
|
|
SET_VARSIZE(poly, size);
|
2003-05-13 20:03:08 +02:00
|
|
|
poly->npts = npts;
|
|
|
|
|
|
|
|
for (i = 0; i < npts; i++)
|
|
|
|
{
|
|
|
|
poly->p[i].x = pq_getmsgfloat8(buf);
|
|
|
|
poly->p[i].y = pq_getmsgfloat8(buf);
|
|
|
|
}
|
|
|
|
|
|
|
|
make_bound_box(poly);
|
|
|
|
|
|
|
|
PG_RETURN_POLYGON_P(poly);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* poly_send - converts polygon to binary format
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
poly_send(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
POLYGON *poly = PG_GETARG_POLYGON_P(0);
|
|
|
|
StringInfoData buf;
|
|
|
|
int32 i;
|
|
|
|
|
|
|
|
pq_begintypsend(&buf);
|
2017-10-12 06:00:46 +02:00
|
|
|
pq_sendint32(&buf, poly->npts);
|
2003-05-13 20:03:08 +02:00
|
|
|
for (i = 0; i < poly->npts; i++)
|
|
|
|
{
|
|
|
|
pq_sendfloat8(&buf, poly->p[i].x);
|
|
|
|
pq_sendfloat8(&buf, poly->p[i].y);
|
|
|
|
}
|
|
|
|
PG_RETURN_BYTEA_P(pq_endtypsend(&buf));
|
|
|
|
}
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
/*-------------------------------------------------------
|
|
|
|
* Is polygon A strictly left of polygon B? i.e. is
|
|
|
|
* the right most point of A left of the left most point
|
|
|
|
* of B?
|
|
|
|
*-------------------------------------------------------*/
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
poly_left(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
POLYGON *polya = PG_GETARG_POLYGON_P(0);
|
|
|
|
POLYGON *polyb = PG_GETARG_POLYGON_P(1);
|
2000-12-09 00:57:03 +01:00
|
|
|
bool result;
|
2000-07-29 20:46:12 +02:00
|
|
|
|
2000-12-09 00:57:03 +01:00
|
|
|
result = polya->boundbox.high.x < polyb->boundbox.low.x;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Avoid leaking memory for toasted inputs ... needed for rtree indexes
|
|
|
|
*/
|
|
|
|
PG_FREE_IF_COPY(polya, 0);
|
|
|
|
PG_FREE_IF_COPY(polyb, 1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(result);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*-------------------------------------------------------
|
|
|
|
* Is polygon A overlapping or left of polygon B? i.e. is
|
2005-06-24 22:53:34 +02:00
|
|
|
* the right most point of A at or left of the right most point
|
1996-07-09 08:22:35 +02:00
|
|
|
* of B?
|
|
|
|
*-------------------------------------------------------*/
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
poly_overleft(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
POLYGON *polya = PG_GETARG_POLYGON_P(0);
|
|
|
|
POLYGON *polyb = PG_GETARG_POLYGON_P(1);
|
2000-12-09 00:57:03 +01:00
|
|
|
bool result;
|
|
|
|
|
2005-06-24 22:53:34 +02:00
|
|
|
result = polya->boundbox.high.x <= polyb->boundbox.high.x;
|
2000-07-29 20:46:12 +02:00
|
|
|
|
2000-12-09 00:57:03 +01:00
|
|
|
/*
|
|
|
|
* Avoid leaking memory for toasted inputs ... needed for rtree indexes
|
|
|
|
*/
|
|
|
|
PG_FREE_IF_COPY(polya, 0);
|
|
|
|
PG_FREE_IF_COPY(polyb, 1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(result);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*-------------------------------------------------------
|
|
|
|
* Is polygon A strictly right of polygon B? i.e. is
|
|
|
|
* the left most point of A right of the right most point
|
|
|
|
* of B?
|
|
|
|
*-------------------------------------------------------*/
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
poly_right(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
POLYGON *polya = PG_GETARG_POLYGON_P(0);
|
|
|
|
POLYGON *polyb = PG_GETARG_POLYGON_P(1);
|
2000-12-09 00:57:03 +01:00
|
|
|
bool result;
|
|
|
|
|
|
|
|
result = polya->boundbox.low.x > polyb->boundbox.high.x;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Avoid leaking memory for toasted inputs ... needed for rtree indexes
|
|
|
|
*/
|
|
|
|
PG_FREE_IF_COPY(polya, 0);
|
|
|
|
PG_FREE_IF_COPY(polyb, 1);
|
2000-07-29 20:46:12 +02:00
|
|
|
|
2000-12-09 00:57:03 +01:00
|
|
|
PG_RETURN_BOOL(result);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*-------------------------------------------------------
|
|
|
|
* Is polygon A overlapping or right of polygon B? i.e. is
|
2005-06-24 22:53:34 +02:00
|
|
|
* the left most point of A at or right of the left most point
|
1996-07-09 08:22:35 +02:00
|
|
|
* of B?
|
|
|
|
*-------------------------------------------------------*/
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
poly_overright(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
POLYGON *polya = PG_GETARG_POLYGON_P(0);
|
|
|
|
POLYGON *polyb = PG_GETARG_POLYGON_P(1);
|
2000-12-09 00:57:03 +01:00
|
|
|
bool result;
|
2000-07-29 20:46:12 +02:00
|
|
|
|
2005-06-24 22:53:34 +02:00
|
|
|
result = polya->boundbox.low.x >= polyb->boundbox.low.x;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Avoid leaking memory for toasted inputs ... needed for rtree indexes
|
|
|
|
*/
|
|
|
|
PG_FREE_IF_COPY(polya, 0);
|
|
|
|
PG_FREE_IF_COPY(polyb, 1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(result);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*-------------------------------------------------------
|
|
|
|
* Is polygon A strictly below polygon B? i.e. is
|
|
|
|
* the upper most point of A below the lower most point
|
|
|
|
* of B?
|
|
|
|
*-------------------------------------------------------*/
|
|
|
|
Datum
|
|
|
|
poly_below(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
POLYGON *polya = PG_GETARG_POLYGON_P(0);
|
|
|
|
POLYGON *polyb = PG_GETARG_POLYGON_P(1);
|
|
|
|
bool result;
|
|
|
|
|
|
|
|
result = polya->boundbox.high.y < polyb->boundbox.low.y;
|
2000-12-09 00:57:03 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Avoid leaking memory for toasted inputs ... needed for rtree indexes
|
|
|
|
*/
|
|
|
|
PG_FREE_IF_COPY(polya, 0);
|
|
|
|
PG_FREE_IF_COPY(polyb, 1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(result);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2005-06-24 22:53:34 +02:00
|
|
|
/*-------------------------------------------------------
|
|
|
|
* Is polygon A overlapping or below polygon B? i.e. is
|
|
|
|
* the upper most point of A at or below the upper most point
|
|
|
|
* of B?
|
|
|
|
*-------------------------------------------------------*/
|
|
|
|
Datum
|
|
|
|
poly_overbelow(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
POLYGON *polya = PG_GETARG_POLYGON_P(0);
|
|
|
|
POLYGON *polyb = PG_GETARG_POLYGON_P(1);
|
|
|
|
bool result;
|
|
|
|
|
|
|
|
result = polya->boundbox.high.y <= polyb->boundbox.high.y;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Avoid leaking memory for toasted inputs ... needed for rtree indexes
|
|
|
|
*/
|
|
|
|
PG_FREE_IF_COPY(polya, 0);
|
|
|
|
PG_FREE_IF_COPY(polyb, 1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(result);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*-------------------------------------------------------
|
|
|
|
* Is polygon A strictly above polygon B? i.e. is
|
|
|
|
* the lower most point of A above the upper most point
|
|
|
|
* of B?
|
|
|
|
*-------------------------------------------------------*/
|
|
|
|
Datum
|
|
|
|
poly_above(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
POLYGON *polya = PG_GETARG_POLYGON_P(0);
|
|
|
|
POLYGON *polyb = PG_GETARG_POLYGON_P(1);
|
|
|
|
bool result;
|
|
|
|
|
|
|
|
result = polya->boundbox.low.y > polyb->boundbox.high.y;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Avoid leaking memory for toasted inputs ... needed for rtree indexes
|
|
|
|
*/
|
|
|
|
PG_FREE_IF_COPY(polya, 0);
|
|
|
|
PG_FREE_IF_COPY(polyb, 1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(result);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*-------------------------------------------------------
|
|
|
|
* Is polygon A overlapping or above polygon B? i.e. is
|
|
|
|
* the lower most point of A at or above the lower most point
|
|
|
|
* of B?
|
|
|
|
*-------------------------------------------------------*/
|
|
|
|
Datum
|
|
|
|
poly_overabove(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
POLYGON *polya = PG_GETARG_POLYGON_P(0);
|
|
|
|
POLYGON *polyb = PG_GETARG_POLYGON_P(1);
|
|
|
|
bool result;
|
|
|
|
|
|
|
|
result = polya->boundbox.low.y >= polyb->boundbox.low.y;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Avoid leaking memory for toasted inputs ... needed for rtree indexes
|
|
|
|
*/
|
|
|
|
PG_FREE_IF_COPY(polya, 0);
|
|
|
|
PG_FREE_IF_COPY(polyb, 1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(result);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*-------------------------------------------------------
|
|
|
|
* Is polygon A the same as polygon B? i.e. are all the
|
|
|
|
* points the same?
|
1997-07-29 18:08:18 +02:00
|
|
|
* Check all points for matches in both forward and reverse
|
|
|
|
* direction since polygons are non-directional and are
|
|
|
|
* closed shapes.
|
1996-07-09 08:22:35 +02:00
|
|
|
*-------------------------------------------------------*/
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
poly_same(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
POLYGON *polya = PG_GETARG_POLYGON_P(0);
|
|
|
|
POLYGON *polyb = PG_GETARG_POLYGON_P(1);
|
2000-12-09 00:57:03 +01:00
|
|
|
bool result;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
if (polya->npts != polyb->npts)
|
2000-12-09 00:57:03 +01:00
|
|
|
result = false;
|
|
|
|
else
|
|
|
|
result = plist_same(polya->npts, polya->p, polyb->p);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Avoid leaking memory for toasted inputs ... needed for rtree indexes
|
|
|
|
*/
|
|
|
|
PG_FREE_IF_COPY(polya, 0);
|
|
|
|
PG_FREE_IF_COPY(polyb, 1);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2000-12-09 00:57:03 +01:00
|
|
|
PG_RETURN_BOOL(result);
|
2000-07-29 20:46:12 +02:00
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
/*-----------------------------------------------------------------
|
2009-07-28 11:48:00 +02:00
|
|
|
* Determine if polygon A overlaps polygon B
|
1996-07-09 08:22:35 +02:00
|
|
|
*-----------------------------------------------------------------*/
|
2021-12-13 23:33:32 +01:00
|
|
|
static bool
|
|
|
|
poly_overlap_internal(POLYGON *polya, POLYGON *polyb)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-12-09 00:57:03 +01:00
|
|
|
bool result;
|
2000-07-29 20:46:12 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
Assert(polya->npts > 0 && polyb->npts > 0);
|
|
|
|
|
2009-07-28 11:48:00 +02:00
|
|
|
/* Quick check by bounding box */
|
2018-07-29 02:02:48 +02:00
|
|
|
result = box_ov(&polya->boundbox, &polyb->boundbox);
|
2009-07-28 11:48:00 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Brute-force algorithm - try to find intersected edges, if so then
|
|
|
|
* polygons are overlapped else check is one polygon inside other or not
|
|
|
|
* by testing single point of them.
|
|
|
|
*/
|
|
|
|
if (result)
|
|
|
|
{
|
|
|
|
int ia,
|
|
|
|
ib;
|
|
|
|
LSEG sa,
|
|
|
|
sb;
|
|
|
|
|
|
|
|
/* Init first of polya's edge with last point */
|
|
|
|
sa.p[0] = polya->p[polya->npts - 1];
|
|
|
|
result = false;
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
for (ia = 0; ia < polya->npts && !result; ia++)
|
2009-07-28 11:48:00 +02:00
|
|
|
{
|
|
|
|
/* Second point of polya's edge is a current one */
|
|
|
|
sa.p[1] = polya->p[ia];
|
|
|
|
|
|
|
|
/* Init first of polyb's edge with last point */
|
|
|
|
sb.p[0] = polyb->p[polyb->npts - 1];
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
for (ib = 0; ib < polyb->npts && !result; ib++)
|
2009-07-28 11:48:00 +02:00
|
|
|
{
|
|
|
|
sb.p[1] = polyb->p[ib];
|
2018-07-29 02:02:48 +02:00
|
|
|
result = lseg_interpt_lseg(NULL, &sa, &sb);
|
2009-07-28 11:48:00 +02:00
|
|
|
sb.p[0] = sb.p[1];
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* move current endpoint to the first point of next edge
|
|
|
|
*/
|
|
|
|
sa.p[0] = sa.p[1];
|
|
|
|
}
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
if (!result)
|
2009-07-28 11:48:00 +02:00
|
|
|
{
|
2018-07-29 02:02:48 +02:00
|
|
|
result = (point_inside(polya->p, polyb->npts, polyb->p) ||
|
2009-07-28 11:48:00 +02:00
|
|
|
point_inside(polyb->p, polya->npts, polya->p));
|
|
|
|
}
|
|
|
|
}
|
2000-12-09 00:57:03 +01:00
|
|
|
|
2021-12-13 23:33:32 +01:00
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
Datum
|
|
|
|
poly_overlap(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
POLYGON *polya = PG_GETARG_POLYGON_P(0);
|
|
|
|
POLYGON *polyb = PG_GETARG_POLYGON_P(1);
|
|
|
|
bool result;
|
|
|
|
|
|
|
|
result = poly_overlap_internal(polya, polyb);
|
|
|
|
|
2000-12-09 00:57:03 +01:00
|
|
|
/*
|
|
|
|
* Avoid leaking memory for toasted inputs ... needed for rtree indexes
|
|
|
|
*/
|
|
|
|
PG_FREE_IF_COPY(polya, 0);
|
|
|
|
PG_FREE_IF_COPY(polyb, 1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(result);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2009-07-28 11:48:00 +02:00
|
|
|
/*
|
|
|
|
* Tests special kind of segment for in/out of polygon.
|
|
|
|
* Special kind means:
|
|
|
|
* - point a should be on segment s
|
|
|
|
* - segment (a,b) should not be contained by s
|
|
|
|
* Returns true if:
|
|
|
|
* - segment (a,b) is collinear to s and (a,b) is in polygon
|
|
|
|
* - segment (a,b) s not collinear to s. Note: that doesn't
|
|
|
|
* mean that segment is in polygon!
|
|
|
|
*/
|
|
|
|
|
|
|
|
static bool
|
|
|
|
touched_lseg_inside_poly(Point *a, Point *b, LSEG *s, POLYGON *poly, int start)
|
|
|
|
{
|
|
|
|
/* point a is on s, b is not */
|
|
|
|
LSEG t;
|
|
|
|
|
|
|
|
t.p[0] = *a;
|
|
|
|
t.p[1] = *b;
|
2010-02-26 03:01:40 +01:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
if (point_eq_point(a, s->p))
|
2009-07-28 11:48:00 +02:00
|
|
|
{
|
2018-07-29 02:02:48 +02:00
|
|
|
if (lseg_contain_point(&t, s->p + 1))
|
2009-07-28 11:48:00 +02:00
|
|
|
return lseg_inside_poly(b, s->p + 1, poly, start);
|
|
|
|
}
|
2018-07-29 02:02:48 +02:00
|
|
|
else if (point_eq_point(a, s->p + 1))
|
2009-07-28 11:48:00 +02:00
|
|
|
{
|
2018-07-29 02:02:48 +02:00
|
|
|
if (lseg_contain_point(&t, s->p))
|
2009-07-28 11:48:00 +02:00
|
|
|
return lseg_inside_poly(b, s->p, poly, start);
|
|
|
|
}
|
2018-07-29 02:02:48 +02:00
|
|
|
else if (lseg_contain_point(&t, s->p))
|
2009-07-28 11:48:00 +02:00
|
|
|
{
|
|
|
|
return lseg_inside_poly(b, s->p, poly, start);
|
|
|
|
}
|
2018-07-29 02:02:48 +02:00
|
|
|
else if (lseg_contain_point(&t, s->p + 1))
|
2009-07-28 11:48:00 +02:00
|
|
|
{
|
|
|
|
return lseg_inside_poly(b, s->p + 1, poly, start);
|
|
|
|
}
|
|
|
|
|
|
|
|
return true; /* may be not true, but that will check later */
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Returns true if segment (a,b) is in polygon, option
|
|
|
|
* start is used for optimization - function checks
|
2018-11-15 16:08:03 +01:00
|
|
|
* polygon's edges starting from start
|
2009-07-28 11:48:00 +02:00
|
|
|
*/
|
|
|
|
static bool
|
|
|
|
lseg_inside_poly(Point *a, Point *b, POLYGON *poly, int start)
|
|
|
|
{
|
|
|
|
LSEG s,
|
|
|
|
t;
|
|
|
|
int i;
|
|
|
|
bool res = true,
|
|
|
|
intersection = false;
|
|
|
|
|
|
|
|
t.p[0] = *a;
|
|
|
|
t.p[1] = *b;
|
|
|
|
s.p[0] = poly->p[(start == 0) ? (poly->npts - 1) : (start - 1)];
|
|
|
|
|
2010-11-15 03:03:48 +01:00
|
|
|
for (i = start; i < poly->npts && res; i++)
|
2009-07-28 11:48:00 +02:00
|
|
|
{
|
2018-07-29 02:02:48 +02:00
|
|
|
Point interpt;
|
2009-07-28 11:48:00 +02:00
|
|
|
|
2015-12-14 20:44:40 +01:00
|
|
|
CHECK_FOR_INTERRUPTS();
|
|
|
|
|
2009-07-28 11:48:00 +02:00
|
|
|
s.p[1] = poly->p[i];
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
if (lseg_contain_point(&s, t.p))
|
2009-07-28 11:48:00 +02:00
|
|
|
{
|
2018-07-29 02:02:48 +02:00
|
|
|
if (lseg_contain_point(&s, t.p + 1))
|
2009-07-28 11:48:00 +02:00
|
|
|
return true; /* t is contained by s */
|
|
|
|
|
|
|
|
/* Y-cross */
|
|
|
|
res = touched_lseg_inside_poly(t.p, t.p + 1, &s, poly, i + 1);
|
|
|
|
}
|
2018-07-29 02:02:48 +02:00
|
|
|
else if (lseg_contain_point(&s, t.p + 1))
|
2009-07-28 11:48:00 +02:00
|
|
|
{
|
|
|
|
/* Y-cross */
|
|
|
|
res = touched_lseg_inside_poly(t.p + 1, t.p, &s, poly, i + 1);
|
|
|
|
}
|
2018-07-29 02:02:48 +02:00
|
|
|
else if (lseg_interpt_lseg(&interpt, &t, &s))
|
2009-07-28 11:48:00 +02:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* segments are X-crossing, go to check each subsegment
|
|
|
|
*/
|
|
|
|
|
|
|
|
intersection = true;
|
2018-07-29 02:02:48 +02:00
|
|
|
res = lseg_inside_poly(t.p, &interpt, poly, i + 1);
|
2009-07-28 11:48:00 +02:00
|
|
|
if (res)
|
2018-07-29 02:02:48 +02:00
|
|
|
res = lseg_inside_poly(t.p + 1, &interpt, poly, i + 1);
|
2009-07-28 11:48:00 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
s.p[0] = s.p[1];
|
|
|
|
}
|
|
|
|
|
|
|
|
if (res && !intersection)
|
|
|
|
{
|
|
|
|
Point p;
|
|
|
|
|
|
|
|
/*
|
2022-04-11 10:49:41 +02:00
|
|
|
* if X-intersection wasn't found, then check central point of tested
|
2009-07-28 11:48:00 +02:00
|
|
|
* segment. In opposite case we already check all subsegments
|
|
|
|
*/
|
2018-08-16 19:56:11 +02:00
|
|
|
p.x = float8_div(float8_pl(t.p[0].x, t.p[1].x), 2.0);
|
|
|
|
p.y = float8_div(float8_pl(t.p[0].y, t.p[1].y), 2.0);
|
2009-07-28 11:48:00 +02:00
|
|
|
|
|
|
|
res = point_inside(&p, poly->npts, poly->p);
|
|
|
|
}
|
|
|
|
|
|
|
|
return res;
|
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2018-11-15 16:08:03 +01:00
|
|
|
/*
|
|
|
|
* Check whether the first polygon contains the second
|
|
|
|
*/
|
2018-07-29 02:02:48 +02:00
|
|
|
static bool
|
2018-11-15 16:08:03 +01:00
|
|
|
poly_contain_poly(POLYGON *contains_poly, POLYGON *contained_poly)
|
1997-07-29 18:08:18 +02:00
|
|
|
{
|
2018-07-29 02:02:48 +02:00
|
|
|
int i;
|
|
|
|
LSEG s;
|
|
|
|
|
2018-11-15 16:08:03 +01:00
|
|
|
Assert(contains_poly->npts > 0 && contained_poly->npts > 0);
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
/*
|
2018-11-15 16:08:03 +01:00
|
|
|
* Quick check to see if contained's bounding box is contained in
|
|
|
|
* contains' bb.
|
2000-07-29 20:46:12 +02:00
|
|
|
*/
|
2018-11-15 16:08:03 +01:00
|
|
|
if (!box_contain_box(&contains_poly->boundbox, &contained_poly->boundbox))
|
2018-07-29 02:02:48 +02:00
|
|
|
return false;
|
2009-07-28 11:48:00 +02:00
|
|
|
|
2018-11-15 16:08:03 +01:00
|
|
|
s.p[0] = contained_poly->p[contained_poly->npts - 1];
|
2009-07-28 11:48:00 +02:00
|
|
|
|
2018-11-15 16:08:03 +01:00
|
|
|
for (i = 0; i < contained_poly->npts; i++)
|
2000-12-09 00:57:03 +01:00
|
|
|
{
|
2018-11-15 16:08:03 +01:00
|
|
|
s.p[1] = contained_poly->p[i];
|
|
|
|
if (!lseg_inside_poly(s.p, s.p + 1, contains_poly, 0))
|
2018-07-29 02:02:48 +02:00
|
|
|
return false;
|
|
|
|
s.p[0] = s.p[1];
|
2000-12-09 00:57:03 +01:00
|
|
|
}
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
Datum
|
|
|
|
poly_contain(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
POLYGON *polya = PG_GETARG_POLYGON_P(0);
|
|
|
|
POLYGON *polyb = PG_GETARG_POLYGON_P(1);
|
|
|
|
bool result;
|
|
|
|
|
|
|
|
result = poly_contain_poly(polya, polyb);
|
|
|
|
|
2000-12-09 00:57:03 +01:00
|
|
|
/*
|
|
|
|
* Avoid leaking memory for toasted inputs ... needed for rtree indexes
|
|
|
|
*/
|
|
|
|
PG_FREE_IF_COPY(polya, 0);
|
|
|
|
PG_FREE_IF_COPY(polyb, 1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(result);
|
2000-07-29 20:46:12 +02:00
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
/*-----------------------------------------------------------------
|
2005-06-24 22:53:34 +02:00
|
|
|
* Determine if polygon A is contained by polygon B
|
1996-07-09 08:22:35 +02:00
|
|
|
*-----------------------------------------------------------------*/
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
poly_contained(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2018-07-29 02:02:48 +02:00
|
|
|
POLYGON *polya = PG_GETARG_POLYGON_P(0);
|
|
|
|
POLYGON *polyb = PG_GETARG_POLYGON_P(1);
|
|
|
|
bool result;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2005-06-24 22:53:34 +02:00
|
|
|
/* Just switch the arguments and pass it off to poly_contain */
|
2018-07-29 02:02:48 +02:00
|
|
|
result = poly_contain_poly(polyb, polya);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Avoid leaking memory for toasted inputs ... needed for rtree indexes
|
|
|
|
*/
|
|
|
|
PG_FREE_IF_COPY(polya, 0);
|
|
|
|
PG_FREE_IF_COPY(polyb, 1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(result);
|
2000-07-29 20:46:12 +02:00
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
|
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
poly_contain_pt(PG_FUNCTION_ARGS)
|
1997-07-29 18:08:18 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
POLYGON *poly = PG_GETARG_POLYGON_P(0);
|
|
|
|
Point *p = PG_GETARG_POINT_P(1);
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_BOOL(point_inside(p, poly->npts, poly->p) != 0);
|
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
pt_contained_poly(PG_FUNCTION_ARGS)
|
1997-07-29 18:08:18 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
Point *p = PG_GETARG_POINT_P(0);
|
|
|
|
POLYGON *poly = PG_GETARG_POLYGON_P(1);
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_BOOL(point_inside(p, poly->npts, poly->p) != 0);
|
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
|
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
poly_distance(PG_FUNCTION_ARGS)
|
1997-07-29 18:08:18 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
POLYGON *polya = PG_GETARG_POLYGON_P(0);
|
|
|
|
POLYGON *polyb = PG_GETARG_POLYGON_P(1);
|
2021-12-13 23:33:32 +01:00
|
|
|
float8 min = 0.0; /* initialize to keep compiler quiet */
|
|
|
|
bool have_min = false;
|
|
|
|
float8 tmp;
|
|
|
|
int i,
|
|
|
|
j;
|
|
|
|
LSEG seg1,
|
|
|
|
seg2;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2021-12-13 23:33:32 +01:00
|
|
|
/*
|
|
|
|
* Distance is zero if polygons overlap. We must check this because the
|
|
|
|
* path distance will not give the right answer if one poly is entirely
|
|
|
|
* within the other.
|
|
|
|
*/
|
|
|
|
if (poly_overlap_internal(polya, polyb))
|
|
|
|
PG_RETURN_FLOAT8(0.0);
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2021-12-13 23:33:32 +01:00
|
|
|
/*
|
|
|
|
* When they don't overlap, the distance calculation is identical to that
|
|
|
|
* for closed paths (i.e., we needn't care about the fact that polygons
|
|
|
|
* include their contained areas). See path_distance().
|
|
|
|
*/
|
|
|
|
for (i = 0; i < polya->npts; i++)
|
|
|
|
{
|
|
|
|
int iprev;
|
|
|
|
|
|
|
|
if (i > 0)
|
|
|
|
iprev = i - 1;
|
|
|
|
else
|
|
|
|
iprev = polya->npts - 1;
|
|
|
|
|
|
|
|
for (j = 0; j < polyb->npts; j++)
|
|
|
|
{
|
|
|
|
int jprev;
|
|
|
|
|
|
|
|
if (j > 0)
|
|
|
|
jprev = j - 1;
|
|
|
|
else
|
|
|
|
jprev = polyb->npts - 1;
|
|
|
|
|
|
|
|
statlseg_construct(&seg1, &polya->p[iprev], &polya->p[i]);
|
|
|
|
statlseg_construct(&seg2, &polyb->p[jprev], &polyb->p[j]);
|
|
|
|
|
|
|
|
tmp = lseg_closept_lseg(NULL, &seg1, &seg2);
|
|
|
|
if (!have_min || float8_lt(tmp, min))
|
|
|
|
{
|
|
|
|
min = tmp;
|
|
|
|
have_min = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!have_min)
|
|
|
|
PG_RETURN_NULL();
|
|
|
|
|
|
|
|
PG_RETURN_FLOAT8(min);
|
2000-07-29 20:46:12 +02:00
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
|
|
|
|
|
|
|
/***********************************************************************
|
|
|
|
**
|
|
|
|
** Routines for 2D points.
|
|
|
|
**
|
|
|
|
***********************************************************************/
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
construct_point(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
float8 x = PG_GETARG_FLOAT8(0);
|
|
|
|
float8 y = PG_GETARG_FLOAT8(1);
|
2018-07-29 02:02:48 +02:00
|
|
|
Point *result;
|
|
|
|
|
|
|
|
result = (Point *) palloc(sizeof(Point));
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
point_construct(result, x, y);
|
|
|
|
|
|
|
|
PG_RETURN_POINT_P(result);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
static inline void
|
|
|
|
point_add_point(Point *result, Point *pt1, Point *pt2)
|
|
|
|
{
|
|
|
|
point_construct(result,
|
2018-08-16 19:56:11 +02:00
|
|
|
float8_pl(pt1->x, pt2->x),
|
|
|
|
float8_pl(pt1->y, pt2->y));
|
2000-07-30 22:44:02 +02:00
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
point_add(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *p1 = PG_GETARG_POINT_P(0);
|
|
|
|
Point *p2 = PG_GETARG_POINT_P(1);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
Point *result;
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
result = (Point *) palloc(sizeof(Point));
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
point_add_point(result, p1, p2);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_POINT_P(result);
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
|
|
|
|
static inline void
|
|
|
|
point_sub_point(Point *result, Point *pt1, Point *pt2)
|
|
|
|
{
|
|
|
|
point_construct(result,
|
2018-08-16 19:56:11 +02:00
|
|
|
float8_mi(pt1->x, pt2->x),
|
|
|
|
float8_mi(pt1->y, pt2->y));
|
2018-07-29 02:02:48 +02:00
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
point_sub(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *p1 = PG_GETARG_POINT_P(0);
|
|
|
|
Point *p2 = PG_GETARG_POINT_P(1);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
Point *result;
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
result = (Point *) palloc(sizeof(Point));
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
point_sub_point(result, p1, p2);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_POINT_P(result);
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
|
|
|
|
static inline void
|
|
|
|
point_mul_point(Point *result, Point *pt1, Point *pt2)
|
|
|
|
{
|
|
|
|
point_construct(result,
|
2018-08-16 19:56:11 +02:00
|
|
|
float8_mi(float8_mul(pt1->x, pt2->x),
|
|
|
|
float8_mul(pt1->y, pt2->y)),
|
|
|
|
float8_pl(float8_mul(pt1->x, pt2->y),
|
|
|
|
float8_mul(pt1->y, pt2->x)));
|
2018-07-29 02:02:48 +02:00
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
point_mul(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *p1 = PG_GETARG_POINT_P(0);
|
|
|
|
Point *p2 = PG_GETARG_POINT_P(1);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
Point *result;
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
result = (Point *) palloc(sizeof(Point));
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
point_mul_point(result, p1, p2);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_POINT_P(result);
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
|
|
|
|
static inline void
|
|
|
|
point_div_point(Point *result, Point *pt1, Point *pt2)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2018-08-16 19:56:11 +02:00
|
|
|
float8 div;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2018-08-16 19:56:11 +02:00
|
|
|
div = float8_pl(float8_mul(pt2->x, pt2->x), float8_mul(pt2->y, pt2->y));
|
1997-08-22 01:57:00 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
point_construct(result,
|
2018-08-16 19:56:11 +02:00
|
|
|
float8_div(float8_pl(float8_mul(pt1->x, pt2->x),
|
|
|
|
float8_mul(pt1->y, pt2->y)), div),
|
|
|
|
float8_div(float8_mi(float8_mul(pt1->y, pt2->x),
|
|
|
|
float8_mul(pt1->x, pt2->y)), div));
|
2018-07-29 02:02:48 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
Datum
|
|
|
|
point_div(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
Point *p1 = PG_GETARG_POINT_P(0);
|
|
|
|
Point *p2 = PG_GETARG_POINT_P(1);
|
|
|
|
Point *result;
|
|
|
|
|
|
|
|
result = (Point *) palloc(sizeof(Point));
|
|
|
|
|
|
|
|
point_div_point(result, p1, p2);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_POINT_P(result);
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
|
|
|
|
|
|
|
/***********************************************************************
|
|
|
|
**
|
|
|
|
** Routines for 2D boxes.
|
|
|
|
**
|
|
|
|
***********************************************************************/
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
points_box(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *p1 = PG_GETARG_POINT_P(0);
|
|
|
|
Point *p2 = PG_GETARG_POINT_P(1);
|
2018-07-29 02:02:48 +02:00
|
|
|
BOX *result;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
result = (BOX *) palloc(sizeof(BOX));
|
|
|
|
|
|
|
|
box_construct(result, p1, p2);
|
|
|
|
|
|
|
|
PG_RETURN_BOX_P(result);
|
2000-07-30 22:44:02 +02:00
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_add(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box = PG_GETARG_BOX_P(0);
|
|
|
|
Point *p = PG_GETARG_POINT_P(1);
|
2018-07-29 02:02:48 +02:00
|
|
|
BOX *result;
|
|
|
|
|
|
|
|
result = (BOX *) palloc(sizeof(BOX));
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
point_add_point(&result->high, &box->high, p);
|
|
|
|
point_add_point(&result->low, &box->low, p);
|
|
|
|
|
|
|
|
PG_RETURN_BOX_P(result);
|
2000-07-30 22:44:02 +02:00
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_sub(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box = PG_GETARG_BOX_P(0);
|
|
|
|
Point *p = PG_GETARG_POINT_P(1);
|
2018-07-29 02:02:48 +02:00
|
|
|
BOX *result;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
result = (BOX *) palloc(sizeof(BOX));
|
|
|
|
|
|
|
|
point_sub_point(&result->high, &box->high, p);
|
|
|
|
point_sub_point(&result->low, &box->low, p);
|
|
|
|
|
|
|
|
PG_RETURN_BOX_P(result);
|
2000-07-30 22:44:02 +02:00
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_mul(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box = PG_GETARG_BOX_P(0);
|
|
|
|
Point *p = PG_GETARG_POINT_P(1);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
BOX *result;
|
2018-07-29 02:02:48 +02:00
|
|
|
Point high,
|
|
|
|
low;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
result = (BOX *) palloc(sizeof(BOX));
|
|
|
|
|
|
|
|
point_mul_point(&high, &box->high, p);
|
|
|
|
point_mul_point(&low, &box->low, p);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
box_construct(result, &high, &low);
|
2000-07-30 22:44:02 +02:00
|
|
|
|
|
|
|
PG_RETURN_BOX_P(result);
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_div(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box = PG_GETARG_BOX_P(0);
|
|
|
|
Point *p = PG_GETARG_POINT_P(1);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
BOX *result;
|
2018-07-29 02:02:48 +02:00
|
|
|
Point high,
|
|
|
|
low;
|
|
|
|
|
|
|
|
result = (BOX *) palloc(sizeof(BOX));
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
point_div_point(&high, &box->high, p);
|
|
|
|
point_div_point(&low, &box->low, p);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
box_construct(result, &high, &low);
|
2000-07-30 22:44:02 +02:00
|
|
|
|
|
|
|
PG_RETURN_BOX_P(result);
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2015-05-05 20:22:24 +02:00
|
|
|
/*
|
|
|
|
* Convert point to empty box
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
point_box(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
Point *pt = PG_GETARG_POINT_P(0);
|
|
|
|
BOX *box;
|
|
|
|
|
|
|
|
box = (BOX *) palloc(sizeof(BOX));
|
|
|
|
|
|
|
|
box->high.x = pt->x;
|
|
|
|
box->low.x = pt->x;
|
|
|
|
box->high.y = pt->y;
|
|
|
|
box->low.y = pt->y;
|
|
|
|
|
|
|
|
PG_RETURN_BOX_P(box);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Smallest bounding box that includes both of the given boxes
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
boxes_bound_box(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
BOX *box1 = PG_GETARG_BOX_P(0),
|
|
|
|
*box2 = PG_GETARG_BOX_P(1),
|
|
|
|
*container;
|
|
|
|
|
|
|
|
container = (BOX *) palloc(sizeof(BOX));
|
|
|
|
|
2018-08-16 19:56:11 +02:00
|
|
|
container->high.x = float8_max(box1->high.x, box2->high.x);
|
|
|
|
container->low.x = float8_min(box1->low.x, box2->low.x);
|
|
|
|
container->high.y = float8_max(box1->high.y, box2->high.y);
|
|
|
|
container->low.y = float8_min(box1->low.y, box2->low.y);
|
2015-05-05 20:22:24 +02:00
|
|
|
|
|
|
|
PG_RETURN_BOX_P(container);
|
|
|
|
}
|
|
|
|
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
|
|
|
/***********************************************************************
|
|
|
|
**
|
|
|
|
** Routines for 2D paths.
|
|
|
|
**
|
|
|
|
***********************************************************************/
|
|
|
|
|
|
|
|
/* path_add()
|
|
|
|
* Concatenate two paths (only if they are both open).
|
|
|
|
*/
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
path_add(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
PATH *p1 = PG_GETARG_PATH_P(0);
|
|
|
|
PATH *p2 = PG_GETARG_PATH_P(1);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
PATH *result;
|
2002-08-30 01:05:44 +02:00
|
|
|
int size,
|
|
|
|
base_size;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
int i;
|
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
if (p1->closed || p2->closed)
|
|
|
|
PG_RETURN_NULL();
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2002-08-30 01:05:44 +02:00
|
|
|
base_size = sizeof(p1->p[0]) * (p1->npts + p2->npts);
|
2015-02-20 06:11:42 +01:00
|
|
|
size = offsetof(PATH, p) + base_size;
|
2002-08-30 01:05:44 +02:00
|
|
|
|
|
|
|
/* Check for integer overflow */
|
|
|
|
if (base_size / sizeof(p1->p[0]) != (p1->npts + p2->npts) ||
|
|
|
|
size <= base_size)
|
2003-07-27 06:53:12 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
|
|
|
|
errmsg("too many points requested")));
|
2002-08-30 01:05:44 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
result = (PATH *) palloc(size);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2007-02-28 00:48:10 +01:00
|
|
|
SET_VARSIZE(result, size);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
result->npts = (p1->npts + p2->npts);
|
|
|
|
result->closed = p1->closed;
|
Fix array- and path-creating functions to ensure padding bytes are zeroes.
Per recent discussion, it's important for all computed datums (not only the
results of input functions) to not contain any ill-defined (uninitialized)
bits. Failing to ensure that can result in equal() reporting that
semantically indistinguishable Consts are not equal, which in turn leads to
bizarre and undesirable planner behavior, such as in a recent example from
David Johnston. We might eventually try to fix this in a general manner by
allowing datatypes to define identity-testing functions, but for now the
path of least resistance is to expect datatypes to force all unused bits
into consistent states.
Per some testing by Noah Misch, array and path functions seem to be the
only ones presenting risks at the moment, so I looked through all the
functions in adt/array*.c and geo_ops.c and fixed them as necessary. In
the array functions, the easiest/safest fix is to allocate result arrays
with palloc0 instead of palloc. Possibly in future someone will want to
look into whether we can just zero the padding bytes, but that looks too
complex for a back-patchable fix. In the path functions, we already had a
precedent in path_in for just zeroing the one known pad field, so duplicate
that code as needed.
Back-patch to all supported branches.
2011-04-27 19:58:36 +02:00
|
|
|
/* prevent instability in unused pad bytes */
|
|
|
|
result->dummy = 0;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
|
|
|
for (i = 0; i < p1->npts; i++)
|
|
|
|
{
|
|
|
|
result->p[i].x = p1->p[i].x;
|
|
|
|
result->p[i].y = p1->p[i].y;
|
1997-09-05 20:13:45 +02:00
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
for (i = 0; i < p2->npts; i++)
|
|
|
|
{
|
|
|
|
result->p[i + p1->npts].x = p2->p[i].x;
|
|
|
|
result->p[i + p1->npts].y = p2->p[i].y;
|
1997-09-05 20:13:45 +02:00
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_PATH_P(result);
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
|
|
|
/* path_add_pt()
|
2000-07-29 20:46:12 +02:00
|
|
|
* Translation operators.
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
*/
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
path_add_pt(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
PATH *path = PG_GETARG_PATH_P_COPY(0);
|
|
|
|
Point *point = PG_GETARG_POINT_P(1);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < path->npts; i++)
|
2018-07-29 02:02:48 +02:00
|
|
|
point_add_point(&path->p[i], &path->p[i], point);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_PATH_P(path);
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
path_sub_pt(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
PATH *path = PG_GETARG_PATH_P_COPY(0);
|
|
|
|
Point *point = PG_GETARG_POINT_P(1);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < path->npts; i++)
|
2018-07-29 02:02:48 +02:00
|
|
|
point_sub_point(&path->p[i], &path->p[i], point);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_PATH_P(path);
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
|
|
|
/* path_mul_pt()
|
|
|
|
* Rotation and scaling operators.
|
|
|
|
*/
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
path_mul_pt(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
PATH *path = PG_GETARG_PATH_P_COPY(0);
|
|
|
|
Point *point = PG_GETARG_POINT_P(1);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < path->npts; i++)
|
2018-07-29 02:02:48 +02:00
|
|
|
point_mul_point(&path->p[i], &path->p[i], point);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_PATH_P(path);
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
path_div_pt(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
PATH *path = PG_GETARG_PATH_P_COPY(0);
|
|
|
|
Point *point = PG_GETARG_POINT_P(1);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < path->npts; i++)
|
2018-07-29 02:02:48 +02:00
|
|
|
point_div_point(&path->p[i], &path->p[i], point);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_PATH_P(path);
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
path_poly(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
PATH *path = PG_GETARG_PATH_P(0);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
POLYGON *poly;
|
|
|
|
int size;
|
|
|
|
int i;
|
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
/* This is not very consistent --- other similar cases return NULL ... */
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
if (!path->closed)
|
2003-07-27 06:53:12 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
|
|
|
|
errmsg("open path cannot be converted to polygon")));
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2014-02-17 15:33:31 +01:00
|
|
|
/*
|
|
|
|
* Never overflows: the old size fit in MaxAllocSize, and the new size is
|
|
|
|
* just a small constant larger.
|
|
|
|
*/
|
2015-02-20 06:11:42 +01:00
|
|
|
size = offsetof(POLYGON, p) + sizeof(poly->p[0]) * path->npts;
|
2000-07-29 20:46:12 +02:00
|
|
|
poly = (POLYGON *) palloc(size);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2007-02-28 00:48:10 +01:00
|
|
|
SET_VARSIZE(poly, size);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
poly->npts = path->npts;
|
|
|
|
|
|
|
|
for (i = 0; i < path->npts; i++)
|
|
|
|
{
|
|
|
|
poly->p[i].x = path->p[i].x;
|
|
|
|
poly->p[i].y = path->p[i].y;
|
1997-09-05 20:13:45 +02:00
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
|
|
|
make_bound_box(poly);
|
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_POLYGON_P(poly);
|
|
|
|
}
|
1997-06-03 16:01:22 +02:00
|
|
|
|
|
|
|
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
/***********************************************************************
|
|
|
|
**
|
|
|
|
** Routines for 2D polygons.
|
|
|
|
**
|
|
|
|
***********************************************************************/
|
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
poly_npoints(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
POLYGON *poly = PG_GETARG_POLYGON_P(0);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_INT32(poly->npts);
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
poly_center(PG_FUNCTION_ARGS)
|
1997-07-29 18:08:18 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
POLYGON *poly = PG_GETARG_POLYGON_P(0);
|
2018-07-29 02:02:48 +02:00
|
|
|
Point *result;
|
|
|
|
CIRCLE circle;
|
|
|
|
|
|
|
|
result = (Point *) palloc(sizeof(Point));
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
poly_to_circle(&circle, poly);
|
|
|
|
*result = circle.center;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
PG_RETURN_POINT_P(result);
|
2000-07-29 20:46:12 +02:00
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
|
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
poly_box(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
POLYGON *poly = PG_GETARG_POLYGON_P(0);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
BOX *box;
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
box = (BOX *) palloc(sizeof(BOX));
|
|
|
|
*box = poly->boundbox;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_BOX_P(box);
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-07-29 18:08:18 +02:00
|
|
|
|
1997-05-06 09:27:51 +02:00
|
|
|
/* box_poly()
|
|
|
|
* Convert a box to a polygon.
|
|
|
|
*/
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
box_poly(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
BOX *box = PG_GETARG_BOX_P(0);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
POLYGON *poly;
|
|
|
|
int size;
|
|
|
|
|
1997-05-06 09:27:51 +02:00
|
|
|
/* map four corners of the box to a polygon */
|
2015-02-20 06:11:42 +01:00
|
|
|
size = offsetof(POLYGON, p) + sizeof(poly->p[0]) * 4;
|
2000-07-29 20:46:12 +02:00
|
|
|
poly = (POLYGON *) palloc(size);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2007-02-28 00:48:10 +01:00
|
|
|
SET_VARSIZE(poly, size);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
poly->npts = 4;
|
|
|
|
|
|
|
|
poly->p[0].x = box->low.x;
|
|
|
|
poly->p[0].y = box->low.y;
|
|
|
|
poly->p[1].x = box->low.x;
|
|
|
|
poly->p[1].y = box->high.y;
|
|
|
|
poly->p[2].x = box->high.x;
|
|
|
|
poly->p[2].y = box->high.y;
|
|
|
|
poly->p[3].x = box->high.x;
|
|
|
|
poly->p[3].y = box->low.y;
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
box_construct(&poly->boundbox, &box->high, &box->low);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_POLYGON_P(poly);
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
poly_path(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
POLYGON *poly = PG_GETARG_POLYGON_P(0);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
PATH *path;
|
|
|
|
int size;
|
|
|
|
int i;
|
|
|
|
|
2014-02-17 15:33:31 +01:00
|
|
|
/*
|
|
|
|
* Never overflows: the old size fit in MaxAllocSize, and the new size is
|
|
|
|
* smaller by a small constant.
|
|
|
|
*/
|
2015-02-20 06:11:42 +01:00
|
|
|
size = offsetof(PATH, p) + sizeof(path->p[0]) * poly->npts;
|
2000-07-29 20:46:12 +02:00
|
|
|
path = (PATH *) palloc(size);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2007-02-28 00:48:10 +01:00
|
|
|
SET_VARSIZE(path, size);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
path->npts = poly->npts;
|
2017-08-16 06:22:32 +02:00
|
|
|
path->closed = true;
|
Fix array- and path-creating functions to ensure padding bytes are zeroes.
Per recent discussion, it's important for all computed datums (not only the
results of input functions) to not contain any ill-defined (uninitialized)
bits. Failing to ensure that can result in equal() reporting that
semantically indistinguishable Consts are not equal, which in turn leads to
bizarre and undesirable planner behavior, such as in a recent example from
David Johnston. We might eventually try to fix this in a general manner by
allowing datatypes to define identity-testing functions, but for now the
path of least resistance is to expect datatypes to force all unused bits
into consistent states.
Per some testing by Noah Misch, array and path functions seem to be the
only ones presenting risks at the moment, so I looked through all the
functions in adt/array*.c and geo_ops.c and fixed them as necessary. In
the array functions, the easiest/safest fix is to allocate result arrays
with palloc0 instead of palloc. Possibly in future someone will want to
look into whether we can just zero the padding bytes, but that looks too
complex for a back-patchable fix. In the path functions, we already had a
precedent in path_in for just zeroing the one known pad field, so duplicate
that code as needed.
Back-patch to all supported branches.
2011-04-27 19:58:36 +02:00
|
|
|
/* prevent instability in unused pad bytes */
|
|
|
|
path->dummy = 0;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
|
|
|
for (i = 0; i < poly->npts; i++)
|
|
|
|
{
|
|
|
|
path->p[i].x = poly->p[i].x;
|
|
|
|
path->p[i].y = poly->p[i].y;
|
1997-09-05 20:13:45 +02:00
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_PATH_P(path);
|
|
|
|
}
|
1997-06-03 16:01:22 +02:00
|
|
|
|
|
|
|
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
/***********************************************************************
|
|
|
|
**
|
|
|
|
** Routines for circles.
|
|
|
|
**
|
|
|
|
***********************************************************************/
|
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
|
|
|
* Formatting and conversion routines.
|
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
|
|
|
/* circle_in - convert a string to internal form.
|
|
|
|
*
|
|
|
|
* External format: (center and radius of circle)
|
2020-04-08 02:50:02 +02:00
|
|
|
* "<(f8,f8),f8>"
|
|
|
|
* also supports quick entry style "f8,f8,f8"
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_in(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
char *str = PG_GETARG_CSTRING(0);
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
CIRCLE *circle = (CIRCLE *) palloc(sizeof(CIRCLE));
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
char *s,
|
|
|
|
*cp;
|
|
|
|
int depth = 0;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
s = str;
|
2000-12-03 21:45:40 +01:00
|
|
|
while (isspace((unsigned char) *s))
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
s++;
|
2020-04-08 02:50:02 +02:00
|
|
|
if (*s == LDELIM_C)
|
|
|
|
depth++, s++;
|
|
|
|
else if (*s == LDELIM)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2020-04-08 02:50:02 +02:00
|
|
|
/* If there are two left parens, consume the first one */
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
cp = (s + 1);
|
2000-12-03 21:45:40 +01:00
|
|
|
while (isspace((unsigned char) *cp))
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
cp++;
|
|
|
|
if (*cp == LDELIM)
|
2020-04-08 02:50:02 +02:00
|
|
|
depth++, s = cp;
|
1997-09-05 20:13:45 +02:00
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2020-04-08 02:50:02 +02:00
|
|
|
/* pair_decode will consume parens around the pair, if any */
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
pair_decode(s, &circle->center.x, &circle->center.y, &s, "circle", str);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
if (*s == DELIM)
|
1997-05-11 17:11:47 +02:00
|
|
|
s++;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
circle->radius = single_decode(s, &s, "circle", str);
|
2018-08-16 19:56:11 +02:00
|
|
|
/* We have to accept NaN. */
|
|
|
|
if (circle->radius < 0.0)
|
2003-07-27 06:53:12 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
errmsg("invalid input syntax for type %s: \"%s\"",
|
|
|
|
"circle", str)));
|
1997-09-07 07:04:48 +02:00
|
|
|
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
while (depth > 0)
|
|
|
|
{
|
2018-07-29 02:02:48 +02:00
|
|
|
if ((*s == RDELIM) || ((*s == RDELIM_C) && (depth == 1)))
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
|
|
|
depth--;
|
|
|
|
s++;
|
2000-12-03 21:45:40 +01:00
|
|
|
while (isspace((unsigned char) *s))
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
s++;
|
|
|
|
}
|
|
|
|
else
|
2003-07-27 06:53:12 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
errmsg("invalid input syntax for type %s: \"%s\"",
|
|
|
|
"circle", str)));
|
1997-09-05 20:13:45 +02:00
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
|
|
|
if (*s != '\0')
|
2003-07-27 06:53:12 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
errmsg("invalid input syntax for type %s: \"%s\"",
|
|
|
|
"circle", str)));
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_CIRCLE_P(circle);
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
|
|
|
/* circle_out - convert a circle to external form.
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_out(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle = PG_GETARG_CIRCLE_P(0);
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
StringInfoData str;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
initStringInfo(&str);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
appendStringInfoChar(&str, LDELIM_C);
|
|
|
|
appendStringInfoChar(&str, LDELIM);
|
|
|
|
pair_encode(circle->center.x, circle->center.y, &str);
|
|
|
|
appendStringInfoChar(&str, RDELIM);
|
|
|
|
appendStringInfoChar(&str, DELIM);
|
|
|
|
single_encode(circle->radius, &str);
|
|
|
|
appendStringInfoChar(&str, RDELIM_C);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
Improve portability of I/O behavior for the geometric types.
Formerly, the geometric I/O routines such as box_in and point_out relied
directly on strtod() and sprintf() for conversion of the float8 component
values of their data types. However, the behavior of those functions is
pretty platform-dependent, especially for edge-case values such as
infinities and NaNs. This was exposed by commit acdf2a8b372aec1d, which
added test cases involving boxes with infinity endpoints, and immediately
failed on Windows and AIX buildfarm members. We solved these problems
years ago in the main float8in and float8out functions, so let's fix it
by making the geometric types use that code instead of depending directly
on the platform-supplied functions.
To do this, refactor the float8in code so that it can be used to parse
just part of a string, and as a convenience make the guts of float8out
usable without going through DirectFunctionCall.
While at it, get rid of geo_ops.c's fairly shaky assumptions about the
maximum output string length for a double, by having it build results in
StringInfo buffers instead of fixed-length strings.
In passing, convert all the "invalid input syntax for type foo" messages
in this area of the code into "invalid input syntax for type %s" to reduce
the number of distinct translatable strings, per recent discussion.
We would have needed a fair number of the latter anyway for code-sharing
reasons, so we might as well just go whole hog.
Note: this patch is by no means intended to guarantee that the geometric
types uniformly behave sanely for infinity or NaN component values.
But any bugs we have in that line were there all along, they were just
harder to reach in a platform-independent way.
2016-03-30 23:25:03 +02:00
|
|
|
PG_RETURN_CSTRING(str.data);
|
2000-07-30 22:44:02 +02:00
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2003-05-13 20:03:08 +02:00
|
|
|
/*
|
|
|
|
* circle_recv - converts external binary format to circle
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
circle_recv(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
StringInfo buf = (StringInfo) PG_GETARG_POINTER(0);
|
|
|
|
CIRCLE *circle;
|
|
|
|
|
|
|
|
circle = (CIRCLE *) palloc(sizeof(CIRCLE));
|
|
|
|
|
|
|
|
circle->center.x = pq_getmsgfloat8(buf);
|
|
|
|
circle->center.y = pq_getmsgfloat8(buf);
|
|
|
|
circle->radius = pq_getmsgfloat8(buf);
|
|
|
|
|
2018-08-16 19:56:11 +02:00
|
|
|
/* We have to accept NaN. */
|
|
|
|
if (circle->radius < 0.0)
|
2003-07-27 06:53:12 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_BINARY_REPRESENTATION),
|
2003-09-29 02:05:25 +02:00
|
|
|
errmsg("invalid radius in external \"circle\" value")));
|
2003-05-13 20:03:08 +02:00
|
|
|
|
|
|
|
PG_RETURN_CIRCLE_P(circle);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* circle_send - converts circle to binary format
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
circle_send(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
CIRCLE *circle = PG_GETARG_CIRCLE_P(0);
|
|
|
|
StringInfoData buf;
|
|
|
|
|
|
|
|
pq_begintypsend(&buf);
|
|
|
|
pq_sendfloat8(&buf, circle->center.x);
|
|
|
|
pq_sendfloat8(&buf, circle->center.y);
|
|
|
|
pq_sendfloat8(&buf, circle->radius);
|
|
|
|
PG_RETURN_BYTEA_P(pq_endtypsend(&buf));
|
|
|
|
}
|
|
|
|
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
|
|
|
* Relational operators for CIRCLEs.
|
|
|
|
* <, >, <=, >=, and == are based on circle area.
|
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
|
|
|
/* circles identical?
|
2018-08-16 19:56:11 +02:00
|
|
|
*
|
|
|
|
* We consider NaNs values to be equal to each other to let those circles
|
|
|
|
* to be found.
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_same(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle1 = PG_GETARG_CIRCLE_P(0);
|
|
|
|
CIRCLE *circle2 = PG_GETARG_CIRCLE_P(1);
|
|
|
|
|
2018-08-16 19:56:11 +02:00
|
|
|
PG_RETURN_BOOL(((isnan(circle1->radius) && isnan(circle1->radius)) ||
|
|
|
|
FPeq(circle1->radius, circle2->radius)) &&
|
2018-07-29 02:02:48 +02:00
|
|
|
point_eq_point(&circle1->center, &circle2->center));
|
2000-07-30 22:44:02 +02:00
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
|
|
|
/* circle_overlap - does circle1 overlap circle2?
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_overlap(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle1 = PG_GETARG_CIRCLE_P(0);
|
|
|
|
CIRCLE *circle2 = PG_GETARG_CIRCLE_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPle(point_dt(&circle1->center, &circle2->center),
|
2018-08-16 19:56:11 +02:00
|
|
|
float8_pl(circle1->radius, circle2->radius)));
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
}
|
|
|
|
|
2005-06-24 22:53:34 +02:00
|
|
|
/* circle_overleft - is the right edge of circle1 at or left of
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
* the right edge of circle2?
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_overleft(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle1 = PG_GETARG_CIRCLE_P(0);
|
|
|
|
CIRCLE *circle2 = PG_GETARG_CIRCLE_P(1);
|
|
|
|
|
2018-08-16 19:56:11 +02:00
|
|
|
PG_RETURN_BOOL(FPle(float8_pl(circle1->center.x, circle1->radius),
|
|
|
|
float8_pl(circle2->center.x, circle2->radius)));
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* circle_left - is circle1 strictly left of circle2?
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_left(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle1 = PG_GETARG_CIRCLE_P(0);
|
|
|
|
CIRCLE *circle2 = PG_GETARG_CIRCLE_P(1);
|
|
|
|
|
2018-08-16 19:56:11 +02:00
|
|
|
PG_RETURN_BOOL(FPlt(float8_pl(circle1->center.x, circle1->radius),
|
|
|
|
float8_mi(circle2->center.x, circle2->radius)));
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* circle_right - is circle1 strictly right of circle2?
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_right(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle1 = PG_GETARG_CIRCLE_P(0);
|
|
|
|
CIRCLE *circle2 = PG_GETARG_CIRCLE_P(1);
|
|
|
|
|
2018-08-16 19:56:11 +02:00
|
|
|
PG_RETURN_BOOL(FPgt(float8_mi(circle1->center.x, circle1->radius),
|
|
|
|
float8_pl(circle2->center.x, circle2->radius)));
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
}
|
|
|
|
|
2005-06-24 22:53:34 +02:00
|
|
|
/* circle_overright - is the left edge of circle1 at or right of
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
* the left edge of circle2?
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_overright(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle1 = PG_GETARG_CIRCLE_P(0);
|
|
|
|
CIRCLE *circle2 = PG_GETARG_CIRCLE_P(1);
|
|
|
|
|
2018-08-16 19:56:11 +02:00
|
|
|
PG_RETURN_BOOL(FPge(float8_mi(circle1->center.x, circle1->radius),
|
|
|
|
float8_mi(circle2->center.x, circle2->radius)));
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* circle_contained - is circle1 contained by circle2?
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_contained(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle1 = PG_GETARG_CIRCLE_P(0);
|
|
|
|
CIRCLE *circle2 = PG_GETARG_CIRCLE_P(1);
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
PG_RETURN_BOOL(FPle(point_dt(&circle1->center, &circle2->center),
|
2018-08-16 19:56:11 +02:00
|
|
|
float8_mi(circle2->radius, circle1->radius)));
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* circle_contain - does circle1 contain circle2?
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_contain(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle1 = PG_GETARG_CIRCLE_P(0);
|
|
|
|
CIRCLE *circle2 = PG_GETARG_CIRCLE_P(1);
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
PG_RETURN_BOOL(FPle(point_dt(&circle1->center, &circle2->center),
|
2018-08-16 19:56:11 +02:00
|
|
|
float8_mi(circle1->radius, circle2->radius)));
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2005-07-01 21:19:05 +02:00
|
|
|
/* circle_below - is circle1 strictly below circle2?
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_below(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle1 = PG_GETARG_CIRCLE_P(0);
|
|
|
|
CIRCLE *circle2 = PG_GETARG_CIRCLE_P(1);
|
|
|
|
|
2018-08-16 19:56:11 +02:00
|
|
|
PG_RETURN_BOOL(FPlt(float8_pl(circle1->center.y, circle1->radius),
|
|
|
|
float8_mi(circle2->center.y, circle2->radius)));
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
}
|
|
|
|
|
2005-07-01 21:19:05 +02:00
|
|
|
/* circle_above - is circle1 strictly above circle2?
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_above(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle1 = PG_GETARG_CIRCLE_P(0);
|
|
|
|
CIRCLE *circle2 = PG_GETARG_CIRCLE_P(1);
|
|
|
|
|
2018-08-16 19:56:11 +02:00
|
|
|
PG_RETURN_BOOL(FPgt(float8_mi(circle1->center.y, circle1->radius),
|
|
|
|
float8_pl(circle2->center.y, circle2->radius)));
|
2005-07-01 21:19:05 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* circle_overbelow - is the upper edge of circle1 at or below
|
|
|
|
* the upper edge of circle2?
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
circle_overbelow(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
CIRCLE *circle1 = PG_GETARG_CIRCLE_P(0);
|
|
|
|
CIRCLE *circle2 = PG_GETARG_CIRCLE_P(1);
|
|
|
|
|
2018-08-16 19:56:11 +02:00
|
|
|
PG_RETURN_BOOL(FPle(float8_pl(circle1->center.y, circle1->radius),
|
|
|
|
float8_pl(circle2->center.y, circle2->radius)));
|
2005-07-01 21:19:05 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* circle_overabove - is the lower edge of circle1 at or above
|
|
|
|
* the lower edge of circle2?
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
circle_overabove(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
CIRCLE *circle1 = PG_GETARG_CIRCLE_P(0);
|
|
|
|
CIRCLE *circle2 = PG_GETARG_CIRCLE_P(1);
|
|
|
|
|
2018-08-16 19:56:11 +02:00
|
|
|
PG_RETURN_BOOL(FPge(float8_mi(circle1->center.y, circle1->radius),
|
|
|
|
float8_mi(circle2->center.y, circle2->radius)));
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* circle_relop - is area(circle1) relop area(circle2), within
|
|
|
|
* our accuracy constraint?
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_eq(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle1 = PG_GETARG_CIRCLE_P(0);
|
|
|
|
CIRCLE *circle2 = PG_GETARG_CIRCLE_P(1);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOOL(FPeq(circle_ar(circle1), circle_ar(circle2)));
|
|
|
|
}
|
|
|
|
|
|
|
|
Datum
|
|
|
|
circle_ne(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle1 = PG_GETARG_CIRCLE_P(0);
|
|
|
|
CIRCLE *circle2 = PG_GETARG_CIRCLE_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPne(circle_ar(circle1), circle_ar(circle2)));
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_lt(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle1 = PG_GETARG_CIRCLE_P(0);
|
|
|
|
CIRCLE *circle2 = PG_GETARG_CIRCLE_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPlt(circle_ar(circle1), circle_ar(circle2)));
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_gt(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle1 = PG_GETARG_CIRCLE_P(0);
|
|
|
|
CIRCLE *circle2 = PG_GETARG_CIRCLE_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPgt(circle_ar(circle1), circle_ar(circle2)));
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_le(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle1 = PG_GETARG_CIRCLE_P(0);
|
|
|
|
CIRCLE *circle2 = PG_GETARG_CIRCLE_P(1);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOOL(FPle(circle_ar(circle1), circle_ar(circle2)));
|
|
|
|
}
|
|
|
|
|
|
|
|
Datum
|
|
|
|
circle_ge(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle1 = PG_GETARG_CIRCLE_P(0);
|
|
|
|
CIRCLE *circle2 = PG_GETARG_CIRCLE_P(1);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPge(circle_ar(circle1), circle_ar(circle2)));
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
|
|
|
* "Arithmetic" operators on circles.
|
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
|
|
|
/* circle_add_pt()
|
|
|
|
* Translation operator.
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_add_pt(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle = PG_GETARG_CIRCLE_P(0);
|
|
|
|
Point *point = PG_GETARG_POINT_P(1);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
CIRCLE *result;
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
result = (CIRCLE *) palloc(sizeof(CIRCLE));
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
point_add_point(&result->center, &circle->center, point);
|
|
|
|
result->radius = circle->radius;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_CIRCLE_P(result);
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_sub_pt(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle = PG_GETARG_CIRCLE_P(0);
|
|
|
|
Point *point = PG_GETARG_POINT_P(1);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
CIRCLE *result;
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
result = (CIRCLE *) palloc(sizeof(CIRCLE));
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
point_sub_point(&result->center, &circle->center, point);
|
|
|
|
result->radius = circle->radius;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_CIRCLE_P(result);
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
|
|
|
|
|
|
|
/* circle_mul_pt()
|
|
|
|
* Rotation and scaling operators.
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_mul_pt(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle = PG_GETARG_CIRCLE_P(0);
|
|
|
|
Point *point = PG_GETARG_POINT_P(1);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
CIRCLE *result;
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
result = (CIRCLE *) palloc(sizeof(CIRCLE));
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
point_mul_point(&result->center, &circle->center, point);
|
2018-08-16 19:56:11 +02:00
|
|
|
result->radius = float8_mul(circle->radius, HYPOT(point->x, point->y));
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_CIRCLE_P(result);
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_div_pt(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle = PG_GETARG_CIRCLE_P(0);
|
|
|
|
Point *point = PG_GETARG_POINT_P(1);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
CIRCLE *result;
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
result = (CIRCLE *) palloc(sizeof(CIRCLE));
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
point_div_point(&result->center, &circle->center, point);
|
2018-08-16 19:56:11 +02:00
|
|
|
result->radius = float8_div(circle->radius, HYPOT(point->x, point->y));
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_CIRCLE_P(result);
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
|
|
|
|
|
|
|
/* circle_area - returns the area of the circle.
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_area(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle = PG_GETARG_CIRCLE_P(0);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_FLOAT8(circle_ar(circle));
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* circle_diameter - returns the diameter of the circle.
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_diameter(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle = PG_GETARG_CIRCLE_P(0);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2018-08-16 19:56:11 +02:00
|
|
|
PG_RETURN_FLOAT8(float8_mul(circle->radius, 2.0));
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* circle_radius - returns the radius of the circle.
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_radius(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle = PG_GETARG_CIRCLE_P(0);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_FLOAT8(circle->radius);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
1997-04-25 20:40:50 +02:00
|
|
|
/* circle_distance - returns the distance between
|
|
|
|
* two circles.
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_distance(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle1 = PG_GETARG_CIRCLE_P(0);
|
|
|
|
CIRCLE *circle2 = PG_GETARG_CIRCLE_P(1);
|
|
|
|
float8 result;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2018-08-16 19:56:11 +02:00
|
|
|
result = float8_mi(point_dt(&circle1->center, &circle2->center),
|
|
|
|
float8_pl(circle1->radius, circle2->radius));
|
|
|
|
if (result < 0.0)
|
|
|
|
result = 0.0;
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_FLOAT8(result);
|
|
|
|
}
|
1997-04-25 20:40:50 +02:00
|
|
|
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_contain_pt(PG_FUNCTION_ARGS)
|
1997-07-29 18:08:18 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle = PG_GETARG_CIRCLE_P(0);
|
|
|
|
Point *point = PG_GETARG_POINT_P(1);
|
2018-08-16 19:56:11 +02:00
|
|
|
float8 d;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
d = point_dt(&circle->center, point);
|
|
|
|
PG_RETURN_BOOL(d <= circle->radius);
|
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
pt_contained_circle(PG_FUNCTION_ARGS)
|
1997-07-29 18:08:18 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *point = PG_GETARG_POINT_P(0);
|
|
|
|
CIRCLE *circle = PG_GETARG_CIRCLE_P(1);
|
2018-08-16 19:56:11 +02:00
|
|
|
float8 d;
|
2000-07-30 22:44:02 +02:00
|
|
|
|
|
|
|
d = point_dt(&circle->center, point);
|
|
|
|
PG_RETURN_BOOL(d <= circle->radius);
|
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
|
|
|
|
|
1997-04-25 20:40:50 +02:00
|
|
|
/* dist_pc - returns the distance between
|
|
|
|
* a point and a circle.
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
dist_pc(PG_FUNCTION_ARGS)
|
1997-04-25 20:40:50 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *point = PG_GETARG_POINT_P(0);
|
|
|
|
CIRCLE *circle = PG_GETARG_CIRCLE_P(1);
|
|
|
|
float8 result;
|
1997-04-25 20:40:50 +02:00
|
|
|
|
2018-08-16 19:56:11 +02:00
|
|
|
result = float8_mi(point_dt(point, &circle->center),
|
|
|
|
circle->radius);
|
|
|
|
if (result < 0.0)
|
|
|
|
result = 0.0;
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_FLOAT8(result);
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2015-05-15 13:26:51 +02:00
|
|
|
/*
|
|
|
|
* Distance from a circle to a point
|
|
|
|
*/
|
|
|
|
Datum
|
|
|
|
dist_cpoint(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
CIRCLE *circle = PG_GETARG_CIRCLE_P(0);
|
|
|
|
Point *point = PG_GETARG_POINT_P(1);
|
|
|
|
float8 result;
|
|
|
|
|
2018-08-16 19:56:11 +02:00
|
|
|
result = float8_mi(point_dt(point, &circle->center), circle->radius);
|
|
|
|
if (result < 0.0)
|
|
|
|
result = 0.0;
|
|
|
|
|
2015-05-15 13:26:51 +02:00
|
|
|
PG_RETURN_FLOAT8(result);
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
|
|
|
/* circle_center - returns the center point of the circle.
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_center(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle = PG_GETARG_CIRCLE_P(0);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
Point *result;
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
result = (Point *) palloc(sizeof(Point));
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
result->x = circle->center.x;
|
|
|
|
result->y = circle->center.y;
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_POINT_P(result);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* circle_ar - returns the area of the circle.
|
|
|
|
*/
|
2018-08-16 19:56:11 +02:00
|
|
|
static float8
|
1997-08-19 23:40:56 +02:00
|
|
|
circle_ar(CIRCLE *circle)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2018-08-16 19:56:11 +02:00
|
|
|
return float8_mul(float8_mul(circle->radius, circle->radius), M_PI);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
|
|
|
* Conversion operators.
|
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
cr_circle(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
Point *center = PG_GETARG_POINT_P(0);
|
|
|
|
float8 radius = PG_GETARG_FLOAT8(1);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
CIRCLE *result;
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
result = (CIRCLE *) palloc(sizeof(CIRCLE));
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
|
|
|
result->center.x = center->x;
|
|
|
|
result->center.y = center->y;
|
2000-07-30 22:44:02 +02:00
|
|
|
result->radius = radius;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_CIRCLE_P(result);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
circle_box(PG_FUNCTION_ARGS)
|
1997-07-29 18:08:18 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
CIRCLE *circle = PG_GETARG_CIRCLE_P(0);
|
1997-07-29 18:08:18 +02:00
|
|
|
BOX *box;
|
2018-08-16 19:56:11 +02:00
|
|
|
float8 delta;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
box = (BOX *) palloc(sizeof(BOX));
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2018-08-16 19:56:11 +02:00
|
|
|
delta = float8_div(circle->radius, sqrt(2.0));
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2018-08-16 19:56:11 +02:00
|
|
|
box->high.x = float8_pl(circle->center.x, delta);
|
|
|
|
box->low.x = float8_mi(circle->center.x, delta);
|
|
|
|
box->high.y = float8_pl(circle->center.y, delta);
|
|
|
|
box->low.y = float8_mi(circle->center.y, delta);
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOX_P(box);
|
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
|
|
|
|
/* box_circle()
|
|
|
|
* Convert a box to a circle.
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
box_circle(PG_FUNCTION_ARGS)
|
1997-07-29 18:08:18 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
BOX *box = PG_GETARG_BOX_P(0);
|
1997-07-29 18:08:18 +02:00
|
|
|
CIRCLE *circle;
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
circle = (CIRCLE *) palloc(sizeof(CIRCLE));
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2018-08-16 19:56:11 +02:00
|
|
|
circle->center.x = float8_div(float8_pl(box->high.x, box->low.x), 2.0);
|
|
|
|
circle->center.y = float8_div(float8_pl(box->high.y, box->low.y), 2.0);
|
1997-07-29 18:08:18 +02:00
|
|
|
|
|
|
|
circle->radius = point_dt(&circle->center, &box->high);
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_CIRCLE_P(circle);
|
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
|
|
|
|
|
2000-06-13 09:35:40 +02:00
|
|
|
Datum
|
|
|
|
circle_poly(PG_FUNCTION_ARGS)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
2000-06-13 09:35:40 +02:00
|
|
|
int32 npts = PG_GETARG_INT32(0);
|
|
|
|
CIRCLE *circle = PG_GETARG_CIRCLE_P(1);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
POLYGON *poly;
|
2002-08-30 01:05:44 +02:00
|
|
|
int base_size,
|
|
|
|
size;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
int i;
|
2018-08-16 19:56:11 +02:00
|
|
|
float8 angle;
|
|
|
|
float8 anglestep;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2003-07-27 06:53:12 +02:00
|
|
|
if (FPzero(circle->radius))
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
2003-09-29 02:05:25 +02:00
|
|
|
errmsg("cannot convert circle with radius zero to polygon")));
|
2003-07-27 06:53:12 +02:00
|
|
|
|
|
|
|
if (npts < 2)
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
|
|
|
|
errmsg("must request at least 2 points")));
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2002-08-30 01:05:44 +02:00
|
|
|
base_size = sizeof(poly->p[0]) * npts;
|
2015-02-20 06:11:42 +01:00
|
|
|
size = offsetof(POLYGON, p) + base_size;
|
2002-08-30 01:05:44 +02:00
|
|
|
|
|
|
|
/* Check for integer overflow */
|
|
|
|
if (base_size / npts != sizeof(poly->p[0]) || size <= base_size)
|
2003-07-27 06:53:12 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
|
|
|
|
errmsg("too many points requested")));
|
2002-08-30 01:05:44 +02:00
|
|
|
|
2002-11-13 01:39:48 +01:00
|
|
|
poly = (POLYGON *) palloc0(size); /* zero any holes */
|
2007-02-28 00:48:10 +01:00
|
|
|
SET_VARSIZE(poly, size);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
poly->npts = npts;
|
|
|
|
|
2018-08-16 19:56:11 +02:00
|
|
|
anglestep = float8_div(2.0 * M_PI, npts);
|
2002-11-08 19:32:47 +01:00
|
|
|
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
for (i = 0; i < npts; i++)
|
|
|
|
{
|
2018-08-16 19:56:11 +02:00
|
|
|
angle = float8_mul(anglestep, i);
|
|
|
|
|
|
|
|
poly->p[i].x = float8_mi(circle->center.x,
|
|
|
|
float8_mul(circle->radius, cos(angle)));
|
|
|
|
poly->p[i].y = float8_pl(circle->center.y,
|
|
|
|
float8_mul(circle->radius, sin(angle)));
|
1997-09-05 20:13:45 +02:00
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
|
|
|
make_bound_box(poly);
|
|
|
|
|
2000-06-13 09:35:40 +02:00
|
|
|
PG_RETURN_POLYGON_P(poly);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
}
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
/*
|
|
|
|
* Convert polygon to circle
|
|
|
|
*
|
|
|
|
* The result must be preallocated.
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
*
|
|
|
|
* XXX This algorithm should use weighted means of line segments
|
|
|
|
* rather than straight average values of points - tgl 97/01/21.
|
|
|
|
*/
|
2018-07-29 02:02:48 +02:00
|
|
|
static void
|
|
|
|
poly_to_circle(CIRCLE *result, POLYGON *poly)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
Assert(poly->npts > 0);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
result->center.x = 0;
|
|
|
|
result->center.y = 0;
|
|
|
|
result->radius = 0;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
|
|
|
for (i = 0; i < poly->npts; i++)
|
2018-07-29 02:02:48 +02:00
|
|
|
point_add_point(&result->center, &result->center, &poly->p[i]);
|
2018-08-16 19:56:11 +02:00
|
|
|
result->center.x = float8_div(result->center.x, poly->npts);
|
|
|
|
result->center.y = float8_div(result->center.y, poly->npts);
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
|
|
|
for (i = 0; i < poly->npts; i++)
|
2018-08-16 19:56:11 +02:00
|
|
|
result->radius = float8_pl(result->radius,
|
|
|
|
point_dt(&poly->p[i], &result->center));
|
|
|
|
result->radius = float8_div(result->radius, poly->npts);
|
2018-07-29 02:02:48 +02:00
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
Datum
|
|
|
|
poly_circle(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
POLYGON *poly = PG_GETARG_POLYGON_P(0);
|
|
|
|
CIRCLE *result;
|
|
|
|
|
|
|
|
result = (CIRCLE *) palloc(sizeof(CIRCLE));
|
|
|
|
|
|
|
|
poly_to_circle(result, poly);
|
|
|
|
|
|
|
|
PG_RETURN_CIRCLE_P(result);
|
2000-07-29 20:46:12 +02:00
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
/***********************************************************************
|
|
|
|
**
|
|
|
|
** Private routines for multiple types.
|
|
|
|
**
|
|
|
|
***********************************************************************/
|
|
|
|
|
2006-06-26 14:32:42 +02:00
|
|
|
/*
|
2007-03-06 00:29:14 +01:00
|
|
|
* Test to see if the point is inside the polygon, returns 1/0, or 2 if
|
|
|
|
* the point is on the polygon.
|
|
|
|
* Code adapted but not copied from integer-based routines in WN: A
|
|
|
|
* Server for the HTTP
|
2006-06-26 14:32:42 +02:00
|
|
|
* version 1.15.1, file wn/image.c
|
|
|
|
* http://hopf.math.northwestern.edu/index.html
|
|
|
|
* Description of algorithm: http://www.linuxjournal.com/article/2197
|
2007-03-06 00:29:14 +01:00
|
|
|
* http://www.linuxjournal.com/article/2029
|
2006-06-26 14:32:42 +02:00
|
|
|
*/
|
|
|
|
|
2007-03-06 00:29:14 +01:00
|
|
|
#define POINT_ON_POLYGON INT_MAX
|
1997-07-29 18:08:18 +02:00
|
|
|
|
1997-08-19 23:40:56 +02:00
|
|
|
static int
|
1997-07-29 18:08:18 +02:00
|
|
|
point_inside(Point *p, int npts, Point *plist)
|
|
|
|
{
|
2018-08-16 19:56:11 +02:00
|
|
|
float8 x0,
|
1997-07-29 18:08:18 +02:00
|
|
|
y0;
|
2018-08-16 19:56:11 +02:00
|
|
|
float8 prev_x,
|
2007-03-06 00:29:14 +01:00
|
|
|
prev_y;
|
|
|
|
int i = 0;
|
2018-08-16 19:56:11 +02:00
|
|
|
float8 x,
|
1997-07-29 18:08:18 +02:00
|
|
|
y;
|
2007-03-06 00:29:14 +01:00
|
|
|
int cross,
|
|
|
|
total_cross = 0;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
Assert(npts > 0);
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2007-03-06 00:29:14 +01:00
|
|
|
/* compute first polygon point relative to single point */
|
2018-08-16 19:56:11 +02:00
|
|
|
x0 = float8_mi(plist[0].x, p->x);
|
|
|
|
y0 = float8_mi(plist[0].y, p->y);
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2007-03-06 00:29:14 +01:00
|
|
|
prev_x = x0;
|
|
|
|
prev_y = y0;
|
|
|
|
/* loop over polygon points and aggregate total_cross */
|
1997-07-29 18:08:18 +02:00
|
|
|
for (i = 1; i < npts; i++)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2007-03-06 00:29:14 +01:00
|
|
|
/* compute next polygon point relative to single point */
|
2018-08-16 19:56:11 +02:00
|
|
|
x = float8_mi(plist[i].x, p->x);
|
|
|
|
y = float8_mi(plist[i].y, p->y);
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2007-03-06 00:29:14 +01:00
|
|
|
/* compute previous to current point crossing */
|
|
|
|
if ((cross = lseg_crossing(x, y, prev_x, prev_y)) == POINT_ON_POLYGON)
|
1997-07-29 18:08:18 +02:00
|
|
|
return 2;
|
2007-03-06 00:29:14 +01:00
|
|
|
total_cross += cross;
|
2007-11-15 22:14:46 +01:00
|
|
|
|
2007-03-06 00:29:14 +01:00
|
|
|
prev_x = x;
|
|
|
|
prev_y = y;
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
2007-03-06 00:29:14 +01:00
|
|
|
|
|
|
|
/* now do the first point */
|
|
|
|
if ((cross = lseg_crossing(x0, y0, prev_x, prev_y)) == POINT_ON_POLYGON)
|
1997-07-29 18:08:18 +02:00
|
|
|
return 2;
|
2007-03-06 00:29:14 +01:00
|
|
|
total_cross += cross;
|
|
|
|
|
|
|
|
if (total_cross != 0)
|
1997-07-29 18:08:18 +02:00
|
|
|
return 1;
|
|
|
|
return 0;
|
2000-07-29 20:46:12 +02:00
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
/* lseg_crossing()
|
2007-03-06 00:29:14 +01:00
|
|
|
* Returns +/-2 if line segment crosses the positive X-axis in a +/- direction.
|
|
|
|
* Returns +/-1 if one point is on the positive X-axis.
|
|
|
|
* Returns 0 if both points are on the positive X-axis, or there is no crossing.
|
|
|
|
* Returns POINT_ON_POLYGON if the segment contains (0,0).
|
|
|
|
* Wow, that is one confusing API, but it is used above, and when summed,
|
|
|
|
* can tell is if a point is in a polygon.
|
1997-07-29 18:08:18 +02:00
|
|
|
*/
|
|
|
|
|
1997-08-19 23:40:56 +02:00
|
|
|
static int
|
2018-08-16 19:56:11 +02:00
|
|
|
lseg_crossing(float8 x, float8 y, float8 prev_x, float8 prev_y)
|
1997-07-29 18:08:18 +02:00
|
|
|
{
|
2018-08-16 19:56:11 +02:00
|
|
|
float8 z;
|
2007-03-06 00:29:14 +01:00
|
|
|
int y_sign;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
|
|
|
if (FPzero(y))
|
2007-03-06 00:29:14 +01:00
|
|
|
{ /* y == 0, on X axis */
|
|
|
|
if (FPzero(x)) /* (x,y) is (0,0)? */
|
|
|
|
return POINT_ON_POLYGON;
|
1997-07-29 18:08:18 +02:00
|
|
|
else if (FPgt(x, 0))
|
2007-03-06 00:29:14 +01:00
|
|
|
{ /* x > 0 */
|
|
|
|
if (FPzero(prev_y)) /* y and prev_y are zero */
|
|
|
|
/* prev_x > 0? */
|
2018-08-16 19:56:11 +02:00
|
|
|
return FPgt(prev_x, 0.0) ? 0 : POINT_ON_POLYGON;
|
|
|
|
return FPlt(prev_y, 0.0) ? 1 : -1;
|
1997-07-29 18:08:18 +02:00
|
|
|
}
|
|
|
|
else
|
2007-03-06 00:29:14 +01:00
|
|
|
{ /* x < 0, x not on positive X axis */
|
|
|
|
if (FPzero(prev_y))
|
|
|
|
/* prev_x < 0? */
|
2018-08-16 19:56:11 +02:00
|
|
|
return FPlt(prev_x, 0.0) ? 0 : POINT_ON_POLYGON;
|
1997-07-29 18:08:18 +02:00
|
|
|
return 0;
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
1997-09-05 20:13:45 +02:00
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
else
|
2007-03-06 00:29:14 +01:00
|
|
|
{ /* y != 0 */
|
|
|
|
/* compute y crossing direction from previous point */
|
2018-08-16 19:56:11 +02:00
|
|
|
y_sign = FPgt(y, 0.0) ? 1 : -1;
|
2007-03-06 00:29:14 +01:00
|
|
|
|
|
|
|
if (FPzero(prev_y))
|
|
|
|
/* previous point was on X axis, so new point is either off or on */
|
2018-08-16 19:56:11 +02:00
|
|
|
return FPlt(prev_x, 0.0) ? 0 : y_sign;
|
|
|
|
else if ((y_sign < 0 && FPlt(prev_y, 0.0)) ||
|
|
|
|
(y_sign > 0 && FPgt(prev_y, 0.0)))
|
2007-03-06 00:29:14 +01:00
|
|
|
/* both above or below X axis */
|
|
|
|
return 0; /* same sign */
|
|
|
|
else
|
|
|
|
{ /* y and prev_y cross X-axis */
|
2018-08-16 19:56:11 +02:00
|
|
|
if (FPge(x, 0.0) && FPgt(prev_x, 0.0))
|
2007-03-06 00:29:14 +01:00
|
|
|
/* both non-negative so cross positive X-axis */
|
|
|
|
return 2 * y_sign;
|
2018-08-16 19:56:11 +02:00
|
|
|
if (FPlt(x, 0.0) && FPle(prev_x, 0.0))
|
2007-03-06 00:29:14 +01:00
|
|
|
/* both non-positive so do not cross positive X-axis */
|
|
|
|
return 0;
|
|
|
|
|
2019-06-03 06:44:03 +02:00
|
|
|
/* x and y cross axes, see URL above point_inside() */
|
2018-08-16 19:56:11 +02:00
|
|
|
z = float8_mi(float8_mul(float8_mi(x, prev_x), y),
|
|
|
|
float8_mul(float8_mi(y, prev_y), x));
|
2007-03-06 00:29:14 +01:00
|
|
|
if (FPzero(z))
|
|
|
|
return POINT_ON_POLYGON;
|
2018-08-16 19:56:11 +02:00
|
|
|
if ((y_sign < 0 && FPlt(z, 0.0)) ||
|
|
|
|
(y_sign > 0 && FPgt(z, 0.0)))
|
|
|
|
return 0;
|
|
|
|
return 2 * y_sign;
|
2007-03-06 00:29:14 +01:00
|
|
|
}
|
1997-09-05 20:13:45 +02:00
|
|
|
}
|
2000-07-30 22:44:02 +02:00
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
|
|
|
|
|
1997-08-19 23:40:56 +02:00
|
|
|
static bool
|
1997-07-29 18:08:18 +02:00
|
|
|
plist_same(int npts, Point *p1, Point *p2)
|
|
|
|
{
|
|
|
|
int i,
|
|
|
|
ii,
|
|
|
|
j;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1997-07-29 18:08:18 +02:00
|
|
|
/* find match for first point */
|
|
|
|
for (i = 0; i < npts; i++)
|
|
|
|
{
|
2018-07-29 02:02:48 +02:00
|
|
|
if (point_eq_point(&p2[i], &p1[0]))
|
1997-07-29 18:08:18 +02:00
|
|
|
{
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1997-07-29 18:08:18 +02:00
|
|
|
/* match found? then look forward through remaining points */
|
|
|
|
for (ii = 1, j = i + 1; ii < npts; ii++, j++)
|
|
|
|
{
|
|
|
|
if (j >= npts)
|
|
|
|
j = 0;
|
2018-07-29 02:02:48 +02:00
|
|
|
if (!point_eq_point(&p2[j], &p1[ii]))
|
1997-07-29 18:08:18 +02:00
|
|
|
break;
|
1997-09-05 20:13:45 +02:00
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
if (ii == npts)
|
2017-08-16 06:22:32 +02:00
|
|
|
return true;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1997-07-29 18:08:18 +02:00
|
|
|
/* match not found forwards? then look backwards */
|
|
|
|
for (ii = 1, j = i - 1; ii < npts; ii++, j--)
|
|
|
|
{
|
|
|
|
if (j < 0)
|
|
|
|
j = (npts - 1);
|
2018-07-29 02:02:48 +02:00
|
|
|
if (!point_eq_point(&p2[j], &p1[ii]))
|
1997-07-29 18:08:18 +02:00
|
|
|
break;
|
1997-09-05 20:13:45 +02:00
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
if (ii == npts)
|
2017-08-16 06:22:32 +02:00
|
|
|
return true;
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
1997-09-05 20:13:45 +02:00
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2017-08-16 06:22:32 +02:00
|
|
|
return false;
|
2000-07-30 22:44:02 +02:00
|
|
|
}
|
2010-08-03 23:21:03 +02:00
|
|
|
|
|
|
|
|
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
* Determine the hypotenuse.
|
|
|
|
*
|
|
|
|
* If required, x and y are swapped to make x the larger number. The
|
|
|
|
* traditional formula of x^2+y^2 is rearranged to factor x outside the
|
|
|
|
* sqrt. This allows computation of the hypotenuse for significantly
|
|
|
|
* larger values, and with a higher precision than when using the naive
|
|
|
|
* formula. In particular, this cannot overflow unless the final result
|
|
|
|
* would be out-of-range.
|
|
|
|
*
|
|
|
|
* sqrt( x^2 + y^2 ) = sqrt( x^2( 1 + y^2/x^2) )
|
|
|
|
* = x * sqrt( 1 + y^2/x^2 )
|
|
|
|
* = x * sqrt( 1 + y/x * y/x )
|
|
|
|
*
|
|
|
|
* It is expected that this routine will eventually be replaced with the
|
|
|
|
* C99 hypot() function.
|
|
|
|
*
|
|
|
|
* This implementation conforms to IEEE Std 1003.1 and GLIBC, in that the
|
|
|
|
* case of hypot(inf,nan) results in INF, and not NAN.
|
|
|
|
*-----------------------------------------------------------------------
|
|
|
|
*/
|
2018-08-16 19:56:11 +02:00
|
|
|
float8
|
|
|
|
pg_hypot(float8 x, float8 y)
|
2010-08-03 23:21:03 +02:00
|
|
|
{
|
2018-08-16 19:56:11 +02:00
|
|
|
float8 yx,
|
|
|
|
result;
|
2010-08-03 23:21:03 +02:00
|
|
|
|
|
|
|
/* Handle INF and NaN properly */
|
|
|
|
if (isinf(x) || isinf(y))
|
|
|
|
return get_float8_infinity();
|
|
|
|
|
|
|
|
if (isnan(x) || isnan(y))
|
|
|
|
return get_float8_nan();
|
|
|
|
|
|
|
|
/* Else, drop any minus signs */
|
|
|
|
x = fabs(x);
|
|
|
|
y = fabs(y);
|
|
|
|
|
|
|
|
/* Swap x and y if needed to make x the larger one */
|
|
|
|
if (x < y)
|
|
|
|
{
|
2018-08-16 19:56:11 +02:00
|
|
|
float8 temp = x;
|
2010-08-03 23:21:03 +02:00
|
|
|
|
|
|
|
x = y;
|
|
|
|
y = temp;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If y is zero, the hypotenuse is x. This test saves a few cycles in
|
|
|
|
* such cases, but more importantly it also protects against
|
|
|
|
* divide-by-zero errors, since now x >= y.
|
|
|
|
*/
|
|
|
|
if (y == 0.0)
|
|
|
|
return x;
|
|
|
|
|
|
|
|
/* Determine the hypotenuse */
|
|
|
|
yx = y / x;
|
2018-08-16 19:56:11 +02:00
|
|
|
result = x * sqrt(1.0 + (yx * yx));
|
|
|
|
|
Avoid a performance regression in float overflow/underflow detection.
Commit 6bf0bc842 replaced float.c's CHECKFLOATVAL() macro with static
inline subroutines, but that wasn't too well thought out. In the original
coding, the unlikely condition (isinf(result) or result == 0) was checked
first, and the inf_is_valid or zero_is_valid condition only afterwards.
The inline-subroutine coding caused that to be swapped around, which is
pretty horrid for performance because (a) in common cases the is_valid
condition is twice as expensive to evaluate (e.g., requiring two isinf()
calls not one) and (b) in common cases the is_valid condition is false,
requiring us to perform the unlikely-condition check anyway. Net result
is that one isinf() call becomes two or three, resulting in visible
performance loss as reported by Keisuke Kuroda.
The original fix proposal was to revert the replacement of the macro,
but on second thought, that macro was just a bad idea from the beginning:
if anything it's a net negative for readability of the code. So instead,
let's just open-code all the overflow/underflow tests, being careful to
test the unlikely condition first (and mark it unlikely() to help the
compiler get the point).
Also, rather than having N copies of the actual ereport() calls, collapse
those into out-of-line error subroutines to save some code space. This
does mean that the error file/line numbers won't be very helpful for
figuring out where the issue really is --- but we'd already burned that
bridge by putting the ereports into static inlines.
In HEAD, check_float[48]_val() are gone altogether. In v12, leave them
present in float.h but unused in the core code, just in case some
extension is depending on them.
Emre Hasegeli, with some kibitzing from me and Andres Freund
Discussion: https://postgr.es/m/CANDwggLe1Gc1OrRqvPfGE=kM9K0FSfia0hbeFCEmwabhLz95AA@mail.gmail.com
2020-02-13 19:37:43 +01:00
|
|
|
if (unlikely(isinf(result)))
|
|
|
|
float_overflow_error();
|
|
|
|
if (unlikely(result == 0.0))
|
|
|
|
float_underflow_error();
|
2018-08-16 19:56:11 +02:00
|
|
|
|
|
|
|
return result;
|
2010-08-03 23:21:03 +02:00
|
|
|
}
|