1996-07-09 08:22:35 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
1999-02-14 00:22:53 +01:00
|
|
|
* geo_ops.c
|
1997-09-07 07:04:48 +02:00
|
|
|
* 2D geometric operations
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
2018-01-03 05:30:12 +01:00
|
|
|
* Portions Copyright (c) 1996-2018, 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"
|
2002-11-08 18:37:52 +01:00
|
|
|
#include "utils/builtins.h"
|
1997-03-15 00:21:12 +01:00
|
|
|
#include "utils/geo_decls.h"
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2002-11-08 19:32:47 +01:00
|
|
|
#ifndef M_PI
|
|
|
|
#define M_PI 3.14159265358979323846
|
1997-07-29 18:08:18 +02:00
|
|
|
#endif
|
|
|
|
|
2002-11-08 19:32:47 +01:00
|
|
|
|
1997-09-20 18:22:31 +02:00
|
|
|
/*
|
|
|
|
* Internal routines
|
|
|
|
*/
|
|
|
|
|
2014-05-06 18:12:18 +02:00
|
|
|
enum path_delim
|
|
|
|
{
|
|
|
|
PATH_NONE, PATH_OPEN, PATH_CLOSED
|
|
|
|
};
|
2013-07-09 04:42:39 +02:00
|
|
|
|
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);
|
1998-09-01 05:29:17 +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);
|
|
|
|
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);
|
1997-09-08 04:41:22 +02:00
|
|
|
static int lseg_crossing(double x, double y, double px, double 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);
|
|
|
|
static float8 lseg_closept_lseg(Point *result, LSEG *l1, LSEG *l2);
|
|
|
|
|
|
|
|
/* 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-07-29 02:02:48 +02:00
|
|
|
static double box_ar(BOX *box);
|
1997-09-08 22:59:27 +02:00
|
|
|
static double box_ht(BOX *box);
|
|
|
|
static double box_wd(BOX *box);
|
2018-07-29 02:02:48 +02:00
|
|
|
static bool box_contain_point(BOX *box, Point *point);
|
|
|
|
static bool box_contain_box(BOX *box1, BOX *box2);
|
|
|
|
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 */
|
1997-09-08 23:56:23 +02:00
|
|
|
static double circle_ar(CIRCLE *circle);
|
2018-07-29 02:02:48 +02:00
|
|
|
|
|
|
|
/* Routines for polygons */
|
1997-09-08 23:56:23 +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);
|
|
|
|
static bool poly_contain_poly(POLYGON *polya, POLYGON *polyb);
|
1998-09-01 05:29:17 +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 */
|
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 double single_decode(char *num, char **endptr_p,
|
|
|
|
const char *type_name, const char *orig_string);
|
|
|
|
static void single_encode(float8 x, StringInfo str);
|
|
|
|
static void pair_decode(char *str, double *x, double *y, char **endptr_p,
|
|
|
|
const char *type_name, const char *orig_string);
|
|
|
|
static void pair_encode(float8 x, float8 y, StringInfo str);
|
1997-09-08 04:41:22 +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.
|
|
|
|
*/
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
#define LDELIM '('
|
|
|
|
#define RDELIM ')'
|
|
|
|
#define DELIM ','
|
|
|
|
#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,
|
1997-09-07 07:04:48 +02:00
|
|
|
* to allow for more predictable usage and data type 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
|
|
|
* The fundamental unit is the point. Other units are line segments,
|
1997-09-07 07:04:48 +02:00
|
|
|
* open paths, boxes, closed paths, and polygons (which should be considered
|
|
|
|
* non-intersecting closed paths).
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
*
|
|
|
|
* Data representation is as follows:
|
1997-09-07 07:04:48 +02:00
|
|
|
* 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))
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data 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 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
|
1997-09-07 07:04:48 +02:00
|
|
|
* fast and correct equality comparisons.
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data 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 perhaps points in complex shapes should be reordered internally
|
1997-09-07 07:04:48 +02:00
|
|
|
* to allow faster internal operations, but should keep track of input order
|
|
|
|
* and restore that order for text output - tgl 97/01/16
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data 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 double
|
|
|
|
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);
|
2017-06-21 20:39:04 +02: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);
|
2017-06-21 20:39:04 +02: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
|
|
|
|
pair_decode(char *str, double *x, double *y, char **endptr_p,
|
|
|
|
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))
|
1997-09-07 07:04:48 +02:00
|
|
|
str++;
|
|
|
|
if ((has_delim = (*str == LDELIM)))
|
|
|
|
str++;
|
|
|
|
|
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);
|
|
|
|
|
1997-09-07 07:04:48 +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))
|
1997-09-07 07:04:48 +02:00
|
|
|
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
|
|
|
/* 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)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
1997-09-08 04:41:22 +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;
|
1997-09-08 04:41:22 +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)))
|
1997-09-07 07:04:48 +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)));
|
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++;
|
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)
|
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
|
|
|
cp = (str + 1);
|
2000-12-03 21:45:40 +01:00
|
|
|
while (isspace((unsigned char) *cp))
|
1997-09-07 07:04:48 +02:00
|
|
|
cp++;
|
|
|
|
if (*cp == LDELIM)
|
|
|
|
{
|
|
|
|
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
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
for (i = 0; i < npts; 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
|
|
|
pair_decode(str, &(p->x), &(p->y), &str, type_name, orig_string);
|
|
|
|
if (*str == DELIM)
|
|
|
|
str++;
|
1997-09-07 07:04:48 +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
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
while (depth > 0)
|
|
|
|
{
|
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)));
|
2017-06-21 20:39:04 +02:00
|
|
|
} /* path_decode() */
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1997-09-08 04:41:22 +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-08 04:41:22 +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
|
|
|
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-08 04:41:22 +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-08 04:41:22 +02:00
|
|
|
break;
|
2013-07-09 04:42:39 +02:00
|
|
|
case PATH_NONE:
|
1997-09-08 04:41:22 +02:00
|
|
|
break;
|
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
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
for (i = 0; i < npts; 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
|
|
|
if (i > 0)
|
|
|
|
appendStringInfoChar(&str, DELIM);
|
|
|
|
appendStringInfoChar(&str, LDELIM);
|
|
|
|
pair_encode(pt->x, pt->y, &str);
|
|
|
|
appendStringInfoChar(&str, RDELIM);
|
1997-09-07 07:04:48 +02:00
|
|
|
pt++;
|
|
|
|
}
|
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-09-08 04:41:22 +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-08 04:41:22 +02:00
|
|
|
break;
|
2013-07-09 04:42:39 +02:00
|
|
|
case PATH_NONE:
|
1997-09-08 04:41:22 +02:00
|
|
|
break;
|
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
|
|
|
return str.data;
|
2017-06-21 20:39:04 +02: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-09-07 07:04:48 +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
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
int ndelim = 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
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
while ((s = strchr(s, delim)) != NULL)
|
|
|
|
{
|
|
|
|
ndelim++;
|
|
|
|
s++;
|
|
|
|
}
|
1998-09-01 05:29:17 +02:00
|
|
|
return (ndelim % 2) ? ((ndelim + 1) / 2) : -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
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/***********************************************************************
|
|
|
|
**
|
1997-09-07 07:04:48 +02:00
|
|
|
** Routines for two-dimensional boxes.
|
1996-07-09 08:22:35 +02:00
|
|
|
**
|
|
|
|
***********************************************************************/
|
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
|
|
|
* Formatting and conversion routines.
|
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* box_in - convert a string to internal form.
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
1997-09-07 07:04:48 +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;
|
1997-09-08 04:41:22 +02:00
|
|
|
double x,
|
|
|
|
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
|
|
|
|
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
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* reorder corners if necessary... */
|
|
|
|
if (box->high.x < box->low.x)
|
|
|
|
{
|
|
|
|
x = box->high.x;
|
|
|
|
box->high.x = box->low.x;
|
|
|
|
box->low.x = x;
|
|
|
|
}
|
|
|
|
if (box->high.y < box->low.y)
|
|
|
|
{
|
|
|
|
y = box->high.y;
|
|
|
|
box->high.y = box->low.y;
|
|
|
|
box->low.y = 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_BOX_P(box);
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* box_out - convert a box to external form.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
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;
|
|
|
|
double x,
|
|
|
|
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... */
|
|
|
|
if (box->high.x < box->low.x)
|
|
|
|
{
|
|
|
|
x = box->high.x;
|
|
|
|
box->high.x = box->low.x;
|
|
|
|
box->low.x = x;
|
|
|
|
}
|
|
|
|
if (box->high.y < box->low.y)
|
|
|
|
{
|
|
|
|
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
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* box_construct - fill in a new box.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
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-07-29 02:02:48 +02:00
|
|
|
if (pt1->x > pt2->x)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2018-07-29 02:02:48 +02:00
|
|
|
result->high.x = pt1->x;
|
|
|
|
result->low.x = pt2->x;
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2018-07-29 02:02:48 +02:00
|
|
|
result->high.x = pt2->x;
|
|
|
|
result->low.x = pt1->x;
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
2018-07-29 02:02:48 +02:00
|
|
|
if (pt1->y > pt2->y)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2018-07-29 02:02:48 +02:00
|
|
|
result->high.y = pt1->y;
|
|
|
|
result->low.y = pt2->y;
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2018-07-29 02:02:48 +02:00
|
|
|
result->high.y = pt2->y;
|
|
|
|
result->low.y = pt1->y;
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* Relational operators for BOXes.
|
|
|
|
* <, >, <=, >=, and == are based on box area.
|
1996-07-09 08:22:35 +02:00
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* box_same - are two boxes identical?
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
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
|
|
|
}
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* box_overlap - does box1 overlap box2?
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
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
|
|
|
}
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* box_right - is box1 strictly right of box2?
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
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
|
1997-09-07 07:04:48 +02:00
|
|
|
* the left edge of box2?
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
1997-09-07 07:04:48 +02:00
|
|
|
* This is "greater than or equal" for time ranges, when time ranges
|
|
|
|
* are stored as rectangles.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
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));
|
|
|
|
}
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* box_contained - is box1 contained by box2?
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
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
|
|
|
}
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* box_contain - does box1 contain box2?
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
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));
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check whether the box is in the box or on its border
|
|
|
|
*/
|
|
|
|
static bool
|
|
|
|
box_contain_box(BOX *box1, BOX *box2)
|
|
|
|
{
|
|
|
|
return FPge(box1->high.x, box2->high.x) &&
|
|
|
|
FPle(box1->low.x, box2->low.x) &&
|
|
|
|
FPge(box1->high.y, box2->high.y) &&
|
|
|
|
FPle(box1->low.y, box2->low.y);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* box_positionop -
|
|
|
|
* 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
|
|
|
}
|
|
|
|
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* box_relop - is area(box1) relop area(box2), within
|
|
|
|
* our accuracy constraint?
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* "Arithmetic" operators on boxes.
|
1996-07-09 08:22:35 +02:00
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* box_area - returns the area of the box.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
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-09-07 07:04:48 +02:00
|
|
|
/* box_width - returns the width of the box
|
|
|
|
* (horizontal magnitude).
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
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
|
|
|
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* box_height - returns the height of the box
|
|
|
|
* (vertical magnitude).
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
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
|
|
|
}
|
|
|
|
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* box_distance - returns the distance between the
|
|
|
|
* center points of two boxes.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
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
|
|
|
}
|
|
|
|
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* box_center - returns the center point of the box.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
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
|
|
|
}
|
|
|
|
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* box_ar - returns the area of the box.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
1997-09-07 07:04:48 +02:00
|
|
|
static double
|
1997-09-08 22:59:27 +02:00
|
|
|
box_ar(BOX *box)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
1998-09-01 05:29:17 +02:00
|
|
|
return 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)
|
|
|
|
{
|
|
|
|
center->x = (box->high.x + box->low.x) / 2.0;
|
|
|
|
center->y = (box->high.y + box->low.y) / 2.0;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* box_wd - returns the width (length) of the box
|
|
|
|
* (horizontal magnitude).
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
1997-09-07 07:04:48 +02:00
|
|
|
static double
|
1997-09-08 22:59:27 +02:00
|
|
|
box_wd(BOX *box)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
1998-09-01 05:29:17 +02:00
|
|
|
return box->high.x - box->low.x;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* box_ht - returns the height of the box
|
|
|
|
* (vertical magnitude).
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
1997-09-07 07:04:48 +02:00
|
|
|
static double
|
1997-09-08 22:59:27 +02:00
|
|
|
box_ht(BOX *box)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
1998-09-01 05:29:17 +02:00
|
|
|
return box->high.y - box->low.y;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* Funky operations.
|
1996-07-09 08:22:35 +02:00
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* box_intersect -
|
|
|
|
* returns the overlapping portion of two boxes,
|
|
|
|
* or NULL if they do not intersect.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
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);
|
1997-09-08 04:41:22 +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
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
result->high.x = Min(box1->high.x, box2->high.x);
|
|
|
|
result->low.x = Max(box1->low.x, box2->low.x);
|
|
|
|
result->high.y = Min(box1->high.y, box2->high.y);
|
|
|
|
result->low.y = 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
|
|
|
}
|
|
|
|
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* box_diagonal -
|
|
|
|
* returns a line segment which happens to be the
|
|
|
|
* positive-slope diagonal of "box".
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
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
|
|
|
}
|
|
|
|
|
|
|
|
/***********************************************************************
|
|
|
|
**
|
1997-09-07 07:04:48 +02:00
|
|
|
** Routines for 2D lines.
|
1996-07-09 08:22:35 +02:00
|
|
|
**
|
|
|
|
***********************************************************************/
|
|
|
|
|
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)
|
|
|
|
{
|
2014-05-06 18:12:18 +02:00
|
|
|
StringInfo buf = (StringInfo) PG_GETARG_POINTER(0);
|
2013-10-09 07:09:18 +02:00
|
|
|
LINE *line;
|
|
|
|
|
|
|
|
line = (LINE *) palloc(sizeof(LINE));
|
|
|
|
|
|
|
|
line->A = pq_getmsgfloat8(buf);
|
|
|
|
line->B = pq_getmsgfloat8(buf);
|
|
|
|
line->C = pq_getmsgfloat8(buf);
|
|
|
|
|
|
|
|
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
|
|
|
/*----------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* Conversion routines from one line formula to internal.
|
|
|
|
* Internal form: Ax+By+C=0
|
1996-07-09 08:22:35 +02:00
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
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
|
|
|
{
|
2000-04-12 19:17:23 +02:00
|
|
|
if (m == DBL_MAX)
|
2010-11-10 22:51:39 +01:00
|
|
|
{
|
|
|
|
/* vertical - use "x = C" */
|
|
|
|
result->A = -1;
|
|
|
|
result->B = 0;
|
|
|
|
result->C = pt->x;
|
|
|
|
}
|
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;
|
1999-12-21 18:01:44 +01:00
|
|
|
result->C = pt->y - m * pt->x;
|
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-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
|
|
|
|
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* Relative position routines.
|
1996-07-09 08:22:35 +02:00
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
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-09-07 07:04:48 +02:00
|
|
|
if (FPzero(l1->A))
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOOL(FPzero(l2->B));
|
1997-09-07 07:04:48 +02:00
|
|
|
else if (FPzero(l1->B))
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOOL(FPzero(l2->A));
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOOL(FPeq(((l1->A * l2->B) / (l1->B * l2->A)), -1.0));
|
|
|
|
}
|
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));
|
|
|
|
}
|
|
|
|
|
|
|
|
Datum
|
|
|
|
line_eq(PG_FUNCTION_ARGS)
|
1997-09-07 07:04:48 +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-09-08 04:41:22 +02:00
|
|
|
double k;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
|
|
|
if (!FPzero(l2->A))
|
|
|
|
k = l1->A / l2->A;
|
|
|
|
else if (!FPzero(l2->B))
|
|
|
|
k = l1->B / l2->B;
|
|
|
|
else if (!FPzero(l2->C))
|
|
|
|
k = l1->C / l2->C;
|
|
|
|
else
|
|
|
|
k = 1.0;
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_BOOL(FPeq(l1->A, k * l2->A) &&
|
|
|
|
FPeq(l1->B, k * l2->B) &&
|
|
|
|
FPeq(l1->C, k * 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
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* Line arithmetic routines.
|
1996-07-09 08:22:35 +02:00
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
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))
|
|
|
|
return DBL_MAX;
|
|
|
|
if (FPzero(line->B))
|
|
|
|
return 0.0;
|
|
|
|
return line->B / line->A;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
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)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
LINE *l1 = PG_GETARG_LINE_P(0);
|
|
|
|
LINE *l2 = PG_GETARG_LINE_P(1);
|
|
|
|
float8 result;
|
2018-07-29 02:02:48 +02:00
|
|
|
Point tmp;
|
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);
|
|
|
|
if (FPzero(l1->B)) /* vertical? */
|
|
|
|
PG_RETURN_FLOAT8(fabs(l1->C - l2->C));
|
2018-07-29 02:02:48 +02:00
|
|
|
point_construct(&tmp, 0.0, l1->C);
|
|
|
|
result = line_closept_point(NULL, l2, &tmp);
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_FLOAT8(result);
|
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-07-29 02:02:48 +02:00
|
|
|
* This returns true if two lines intersect (they do, if they are not
|
|
|
|
* parallel), false if they do not. This also sets the intersection point
|
|
|
|
* to *result, if it is not NULL.
|
|
|
|
*
|
|
|
|
* 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.
|
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
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
double x,
|
|
|
|
y;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
if (FPzero(l1->B)) /* l1 vertical? */
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2018-07-29 02:02:48 +02:00
|
|
|
if (FPzero(l2->B)) /* l2 vertical? */
|
|
|
|
return false;
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
x = l1->C;
|
|
|
|
y = (l2->A * x + l2->C);
|
|
|
|
}
|
2000-07-30 22:44:02 +02:00
|
|
|
else if (FPzero(l2->B)) /* l2 vertical? */
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
|
|
|
x = l2->C;
|
|
|
|
y = (l1->A * x + l1->C);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2018-07-29 02:02:48 +02:00
|
|
|
if (FPeq(l2->A, l1->A * (l2->B / l1->B)))
|
|
|
|
return false;
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
x = (l1->C - l2->C) / (l2->A - l1->A);
|
|
|
|
y = (l1->A * x + l1->C);
|
|
|
|
}
|
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
|
|
|
|
|
|
|
/***********************************************************************
|
|
|
|
**
|
1997-09-07 07:04:48 +02:00
|
|
|
** Routines for 2D paths (sequences of line segments, also
|
|
|
|
** called `polylines').
|
1996-07-09 08:22:35 +02:00
|
|
|
**
|
1997-09-07 07:04:48 +02:00
|
|
|
** 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.
|
1996-07-09 08:22:35 +02:00
|
|
|
**
|
|
|
|
***********************************************************************/
|
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* String to path / path to string conversion.
|
|
|
|
* External format:
|
|
|
|
* "((xcoord, ycoord),... )"
|
|
|
|
* "[(xcoord, ycoord),... ]"
|
|
|
|
* "(xcoord, ycoord),... "
|
|
|
|
* "[xcoord, ycoord,... ]"
|
|
|
|
* Also support older format:
|
|
|
|
* "(closed, npts, xcoord, ycoord,... )"
|
1996-07-09 08:22:35 +02:00
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
2004-05-26 20:35:51 +02:00
|
|
|
Datum
|
|
|
|
path_area(PG_FUNCTION_ARGS)
|
|
|
|
{
|
2004-08-29 07:07:03 +02:00
|
|
|
PATH *path = PG_GETARG_PATH_P(0);
|
|
|
|
double area = 0.0;
|
|
|
|
int i,
|
|
|
|
j;
|
2004-05-26 20:35:51 +02:00
|
|
|
|
|
|
|
if (!path->closed)
|
|
|
|
PG_RETURN_NULL();
|
|
|
|
|
2004-08-29 07:07:03 +02:00
|
|
|
for (i = 0; i < path->npts; i++)
|
|
|
|
{
|
2004-05-26 20:35:51 +02:00
|
|
|
j = (i + 1) % path->npts;
|
|
|
|
area += path->p[i].x * path->p[j].y;
|
|
|
|
area -= path->p[i].y * path->p[j].x;
|
|
|
|
}
|
|
|
|
|
|
|
|
area *= 0.5;
|
|
|
|
PG_RETURN_FLOAT8(area < 0.0 ? -area : area);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
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);
|
1997-09-08 04:41:22 +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;
|
1997-09-08 04:41:22 +02:00
|
|
|
char *s;
|
|
|
|
int npts;
|
|
|
|
int size;
|
2014-02-17 15:33:31 +01:00
|
|
|
int base_size;
|
1997-09-08 04:41: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
|
|
|
|
1997-09-07 07:04:48 +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
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
s = str;
|
2000-12-03 21:45:40 +01:00
|
|
|
while (isspace((unsigned char) *s))
|
1997-09-07 07:04:48 +02:00
|
|
|
s++;
|
1997-06-03 16:01:22 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* skip single leading paren */
|
|
|
|
if ((*s == LDELIM) && (strrchr(s, LDELIM) == s))
|
|
|
|
{
|
|
|
|
s++;
|
|
|
|
depth++;
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data 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;
|
2017-06-21 20:39:04 +02: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-09-07 07:04:48 +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-09-07 07:04:48 +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),
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
errmsg("invalid number of points in external \"path\" value")));
|
2003-05-13 20:03:08 +02:00
|
|
|
|
2017-06-21 20:39:04 +02: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
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* Relational operators.
|
|
|
|
* These are based on the path cardinality,
|
|
|
|
* as stupid as that sounds.
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
1997-09-07 07:04:48 +02:00
|
|
|
* Better relops and access methods coming soon.
|
1996-07-09 08:22:35 +02:00
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
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
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
PG_RETURN_BOOL(!path->closed);
|
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
|
|
|
|
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 -
|
1997-09-07 07:04:48 +02:00
|
|
|
* 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)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
PATH *p1 = PG_GETARG_PATH_P(0);
|
|
|
|
PATH *p2 = PG_GETARG_PATH_P(1);
|
1997-09-08 04:41:22 +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
|
|
|
|
1997-09-07 07:04:48 +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++)
|
|
|
|
{
|
|
|
|
b1.high.x = Max(p1->p[i].x, b1.high.x);
|
|
|
|
b1.high.y = Max(p1->p[i].y, b1.high.y);
|
|
|
|
b1.low.x = Min(p1->p[i].x, b1.low.x);
|
|
|
|
b1.low.y = Min(p1->p[i].y, b1.low.y);
|
|
|
|
}
|
|
|
|
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++)
|
|
|
|
{
|
|
|
|
b2.high.x = Max(p2->p[i].x, b2.high.x);
|
|
|
|
b2.high.y = Max(p2->p[i].y, b2.high.y);
|
|
|
|
b2.low.x = Min(p2->p[i].x, b2.low.x);
|
|
|
|
b2.low.y = Min(p2->p[i].y, b2.low.y);
|
|
|
|
}
|
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
|
|
|
|
|
|
|
/* pairwise check lseg intersections */
|
2001-10-13 19:40:24 +02:00
|
|
|
for (i = 0; i < p1->npts; i++)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2001-10-25 07:50:21 +02:00
|
|
|
int iprev;
|
2001-10-13 19:40:24 +02:00
|
|
|
|
|
|
|
if (i > 0)
|
2001-10-25 07:50:21 +02:00
|
|
|
iprev = i - 1;
|
2001-10-13 19:40:24 +02:00
|
|
|
else
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2001-10-13 19:40:24 +02:00
|
|
|
if (!p1->closed)
|
|
|
|
continue;
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
iprev = p1->npts - 1; /* include the closure segment */
|
2001-10-13 19:40:24 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
for (j = 0; j < p2->npts; j++)
|
|
|
|
{
|
2001-10-25 07:50:21 +02:00
|
|
|
int jprev;
|
2001-10-13 19:40:24 +02:00
|
|
|
|
|
|
|
if (j > 0)
|
2001-10-25 07:50:21 +02:00
|
|
|
jprev = j - 1;
|
2001-10-13 19:40:24 +02:00
|
|
|
else
|
|
|
|
{
|
|
|
|
if (!p2->closed)
|
|
|
|
continue;
|
2001-10-25 07:50:21 +02:00
|
|
|
jprev = p2->npts - 1; /* include the closure segment */
|
2001-10-13 19:40:24 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
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);
|
1997-09-07 07:04:48 +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;
|
1997-09-08 04:41:22 +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-25 07:50:21 +02:00
|
|
|
int iprev;
|
2001-10-13 19:40:24 +02:00
|
|
|
|
|
|
|
if (i > 0)
|
2001-10-25 07:50:21 +02:00
|
|
|
iprev = i - 1;
|
2001-10-13 19:40:24 +02:00
|
|
|
else
|
|
|
|
{
|
|
|
|
if (!p1->closed)
|
|
|
|
continue;
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
iprev = p1->npts - 1; /* include the closure segment */
|
2001-10-13 19:40:24 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
for (j = 0; j < p2->npts; j++)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2001-10-25 07:50:21 +02:00
|
|
|
int jprev;
|
2001-10-13 19:40:24 +02:00
|
|
|
|
|
|
|
if (j > 0)
|
2001-10-25 07:50:21 +02:00
|
|
|
jprev = j - 1;
|
2001-10-13 19:40:24 +02:00
|
|
|
else
|
|
|
|
{
|
|
|
|
if (!p2->closed)
|
|
|
|
continue;
|
2001-10-25 07:50:21 +02:00
|
|
|
jprev = p2->npts - 1; /* include the closure segment */
|
2001-10-13 19:40:24 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
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);
|
2000-07-30 22:44:02 +02:00
|
|
|
if (!have_min || tmp < min)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
min = tmp;
|
|
|
|
have_min = true;
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
1997-09-05 20:13:45 +02:00
|
|
|
}
|
2000-07-29 20:46:12 +02:00
|
|
|
}
|
|
|
|
|
2001-03-22 05:01:46 +01: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
|
|
|
|
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* "Arithmetic" operations.
|
1996-07-09 08:22:35 +02:00
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
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-09-08 04:41:22 +02:00
|
|
|
int i;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2001-10-13 19:40:24 +02:00
|
|
|
for (i = 0; i < path->npts; i++)
|
|
|
|
{
|
2001-10-25 07:50:21 +02:00
|
|
|
int iprev;
|
2001-10-13 19:40:24 +02:00
|
|
|
|
|
|
|
if (i > 0)
|
2001-10-25 07:50:21 +02:00
|
|
|
iprev = i - 1;
|
2001-10-13 19:40:24 +02:00
|
|
|
else
|
|
|
|
{
|
|
|
|
if (!path->closed)
|
|
|
|
continue;
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
iprev = path->npts - 1; /* include the closure segment */
|
2001-10-13 19:40:24 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
result += point_dt(&path->p[iprev], &path->p[i]);
|
|
|
|
}
|
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
|
|
|
/***********************************************************************
|
|
|
|
**
|
1997-09-07 07:04:48 +02:00
|
|
|
** Routines for 2D points.
|
1996-07-09 08:22:35 +02:00
|
|
|
**
|
|
|
|
***********************************************************************/
|
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* String to point, point to string conversion.
|
|
|
|
* 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
|
|
|
{
|
1997-09-07 07:04:48 +02:00
|
|
|
result->x = x;
|
|
|
|
result->y = y;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* 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).
|
1996-07-09 08:22:35 +02:00
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
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));
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline bool
|
|
|
|
point_eq_point(Point *pt1, Point *pt2)
|
|
|
|
{
|
|
|
|
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
|
|
|
/*----------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* "Arithmetic" operators on points.
|
1996-07-09 08:22:35 +02:00
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
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
|
1997-09-08 23:56:23 +02:00
|
|
|
point_dt(Point *pt1, Point *pt2)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
1998-09-01 05:29:17 +02:00
|
|
|
return HYPOT(pt1->x - pt2->x, 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
|
|
|
|
*
|
|
|
|
* Note that this function returns DBL_MAX when the points are the same.
|
|
|
|
*/
|
|
|
|
static inline float8
|
1997-09-08 23:56:23 +02:00
|
|
|
point_sl(Point *pt1, Point *pt2)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2018-07-29 02:02:48 +02:00
|
|
|
if (FPeq(pt1->x, pt2->x))
|
|
|
|
return DBL_MAX;
|
|
|
|
if (FPeq(pt1->y, pt2->y))
|
|
|
|
return 0.0;
|
|
|
|
return (pt1->y - pt2->y) / (pt1->x - pt2->x);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 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))
|
|
|
|
return DBL_MAX;
|
|
|
|
return (pt1->x - pt2->x) / (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
|
|
|
/***********************************************************************
|
|
|
|
**
|
1997-09-07 07:04:48 +02:00
|
|
|
** Routines for 2D line segments.
|
1996-07-09 08:22:35 +02:00
|
|
|
**
|
|
|
|
***********************************************************************/
|
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* String to lseg, lseg to string conversion.
|
|
|
|
* 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 -
|
1997-09-07 07:04:48 +02:00
|
|
|
* form a LSEG from two Points.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
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-09-08 23:56:23 +02:00
|
|
|
statlseg_construct(LSEG *lseg, Point *pt1, Point *pt2)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
1997-09-07 07:04:48 +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;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
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
|
|
|
/*----------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* Relative position routines.
|
1996-07-09 08:22:35 +02:00
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
|
|
|
/*
|
1997-09-07 07:04:48 +02:00
|
|
|
** find intersection of the two lines, and see if it falls on
|
1996-07-09 08:22:35 +02:00
|
|
|
** both segments.
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
lseg_intersect(PG_FUNCTION_ARGS)
|
1997-09-07 07:04:48 +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
|
|
|
|
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* Line arithmetic routines.
|
1996-07-09 08:22:35 +02:00
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
|
|
|
/* lseg_distance -
|
1997-09-07 07:04:48 +02:00
|
|
|
* If two segments don't intersect, then the closest
|
|
|
|
* point will be from one of the endpoints to the other
|
|
|
|
* segment.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
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-09-08 04:41:22 +02:00
|
|
|
Point *result;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
result = (Point *) palloc(sizeof(Point));
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2002-12-30 03:18:29 +01:00
|
|
|
result->x = (lseg->p[0].x + lseg->p[1].x) / 2.0;
|
|
|
|
result->y = (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
|
|
|
|
|
|
|
/*
|
|
|
|
* Find the intersection point of two segments (if any).
|
|
|
|
*
|
|
|
|
* This returns true if two line segments intersect, false if they do not.
|
|
|
|
* This also sets the intersection point to *result, if it is not NULL.
|
|
|
|
* 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)
|
1997-09-07 07:04:48 +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
|
|
|
|
|
|
|
/***********************************************************************
|
|
|
|
**
|
1997-09-07 07:04:48 +02:00
|
|
|
** Routines for position comparisons of differently-typed
|
|
|
|
** 2D objects.
|
1996-07-09 08:22:35 +02:00
|
|
|
**
|
|
|
|
***********************************************************************/
|
|
|
|
|
|
|
|
/*---------------------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* dist_
|
|
|
|
* Minimum distance from one object to another.
|
1996-07-09 08:22:35 +02:00
|
|
|
*-------------------------------------------------------------------*/
|
|
|
|
|
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
|
|
|
|
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
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2014-12-15 16:02:49 +01:00
|
|
|
* Distance from a point to a path
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
dist_ppath(PG_FUNCTION_ARGS)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
Point *pt = PG_GETARG_POINT_P(0);
|
|
|
|
PATH *path = PG_GETARG_PATH_P(1);
|
|
|
|
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;
|
1997-09-08 04:41:22 +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);
|
|
|
|
if (!have_min || tmp < result)
|
|
|
|
{
|
|
|
|
result = tmp;
|
|
|
|
have_min = true;
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
2018-07-29 02:02:48 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_FLOAT8(result);
|
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
|
|
|
}
|
|
|
|
|
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);
|
|
|
|
float8 result,
|
|
|
|
d2;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data 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
|
|
|
if (lseg_interpt_line(NULL, lseg, line))
|
2000-07-30 22:44:02 +02:00
|
|
|
result = 0.0;
|
1997-09-07 07:04:48 +02:00
|
|
|
else
|
|
|
|
{
|
2018-07-29 02:02:48 +02:00
|
|
|
result = line_closept_point(NULL, line, &lseg->p[0]);
|
|
|
|
d2 = line_closept_point(NULL, line, &lseg->p[1]);
|
2000-07-30 22:44:02 +02:00
|
|
|
/* XXX shouldn't we take the min not max? */
|
|
|
|
if (d2 > result)
|
1997-09-07 07:04:48 +02:00
|
|
|
result = d2;
|
|
|
|
}
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_FLOAT8(result);
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
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
|
|
|
}
|
|
|
|
|
2014-12-15 16:02:49 +01:00
|
|
|
/*
|
|
|
|
* Distance from a line to a box
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
dist_lb(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
#ifdef NOT_USED
|
|
|
|
LINE *line = PG_GETARG_LINE_P(0);
|
|
|
|
BOX *box = PG_GETARG_BOX_P(1);
|
|
|
|
#endif
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2002-05-14 20:16:51 +02:00
|
|
|
/* need to think about this one for a while */
|
2003-07-27 06:53:12 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
2003-09-25 08:58:07 +02:00
|
|
|
errmsg("function \"dist_lb\" not implemented")));
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_NULL();
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
2014-12-15 16:02:49 +01:00
|
|
|
/*
|
|
|
|
* Distance from a circle to a polygon
|
|
|
|
*/
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
dist_cpoly(PG_FUNCTION_ARGS)
|
1997-07-29 18:08:18 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
CIRCLE *circle = PG_GETARG_CIRCLE_P(0);
|
2001-03-22 05:01:46 +01:00
|
|
|
POLYGON *poly = PG_GETARG_POLYGON_P(1);
|
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 */
|
|
|
|
result = dist_ppoly_internal(&circle->center, poly);
|
|
|
|
|
|
|
|
result -= circle->radius;
|
|
|
|
if (result < 0)
|
|
|
|
result = 0;
|
|
|
|
|
|
|
|
PG_RETURN_FLOAT8(result);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 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
|
|
|
}
|
|
|
|
|
2014-12-15 16:02:49 +01:00
|
|
|
static double
|
|
|
|
dist_ppoly_internal(Point *pt, POLYGON *poly)
|
|
|
|
{
|
|
|
|
float8 result;
|
2000-07-29 20:46:12 +02:00
|
|
|
float8 d;
|
1997-09-08 04:41:22 +02:00
|
|
|
int i;
|
|
|
|
LSEG seg;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2014-12-15 16:02:49 +01:00
|
|
|
if (point_inside(pt, poly->npts, poly->p) != 0)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
1997-07-29 18:08:18 +02:00
|
|
|
#ifdef GEODEBUG
|
2014-12-15 16:02:49 +01:00
|
|
|
printf("dist_ppoly_internal- point inside of polygon\n");
|
1997-07-29 18:08:18 +02:00
|
|
|
#endif
|
2014-12-15 20:04:27 +01:00
|
|
|
return 0.0;
|
1997-09-07 07:04:48 +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
|
|
|
#ifdef GEODEBUG
|
2014-12-15 16:02:49 +01:00
|
|
|
printf("dist_ppoly_internal- segment 0/n distance is %f\n", result);
|
1997-07-29 18:08:18 +02:00
|
|
|
#endif
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* check distances for other segments */
|
2018-07-29 02:02:48 +02:00
|
|
|
for (i = 0; i < poly->npts - 1; i++)
|
1997-09-07 07:04:48 +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);
|
1997-07-29 18:08:18 +02:00
|
|
|
#ifdef GEODEBUG
|
2014-12-15 16:02:49 +01:00
|
|
|
printf("dist_ppoly_internal- segment %d distance is %f\n", (i + 1), d);
|
1997-07-29 18:08:18 +02:00
|
|
|
#endif
|
2000-07-29 20:46:12 +02:00
|
|
|
if (d < result)
|
|
|
|
result = d;
|
1997-09-07 07:04:48 +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
|
|
|
/*---------------------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* interpt_
|
|
|
|
* Intersection point of objects.
|
|
|
|
* We choose to ignore the "point" of intersection between
|
|
|
|
* lines and boxes, since there are typically two.
|
1996-07-09 08:22:35 +02:00
|
|
|
*-------------------------------------------------------------------*/
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
/*
|
|
|
|
* Check if the line segment intersects with the line
|
|
|
|
*
|
|
|
|
* This returns true if line segment intersects with line, false if they
|
|
|
|
* do not. This also sets the intersection point to *result, if it is not
|
|
|
|
* NULL.
|
|
|
|
*/
|
|
|
|
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;
|
2000-07-30 22:44:02 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
if (result == NULL)
|
2000-07-30 22:44:02 +02:00
|
|
|
return true;
|
2018-07-29 02:02:48 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* 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;
|
|
|
|
|
|
|
|
return true;
|
2000-07-30 22:44:02 +02:00
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
/*---------------------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* close_
|
|
|
|
* Point of closest proximity between objects.
|
1996-07-09 08:22:35 +02:00
|
|
|
*-------------------------------------------------------------------*/
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
/*
|
1997-09-07 07:04:48 +02:00
|
|
|
* The intersection point of a perpendicular of the line
|
|
|
|
* through the point.
|
2018-07-29 02:02:48 +02:00
|
|
|
*
|
|
|
|
* This sets the closest point to the *result if it is not NULL and returns
|
|
|
|
* the distance to the closest point.
|
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)
|
|
|
|
{
|
|
|
|
bool retval;
|
|
|
|
Point closept;
|
|
|
|
LINE tmp;
|
|
|
|
|
|
|
|
/* We drop a perpendicular to find the intersection point. */
|
|
|
|
line_construct(&tmp, point, line_invsl(line));
|
|
|
|
retval = line_interpt_line(&closept, line, &tmp);
|
|
|
|
Assert(retval); /* XXX: We need something better. */
|
|
|
|
|
|
|
|
if (result != NULL)
|
|
|
|
*result = closept;
|
|
|
|
|
|
|
|
/* Then we calculate the distance between the points. */
|
|
|
|
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);
|
1997-09-08 04:41:22 +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-07-29 02:02:48 +02:00
|
|
|
line_closept_point(result, line, pt);
|
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-07-29 02:02:48 +02:00
|
|
|
* This sets the closest point to the *result if it is not NULL and returns
|
|
|
|
* the distance to the closest point.
|
1997-09-07 07:04:48 +02:00
|
|
|
*/
|
2018-07-29 02:02:48 +02:00
|
|
|
static float8
|
|
|
|
lseg_closept_point(Point *result, LSEG *lseg, Point *pt)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
2018-07-29 02:02:48 +02:00
|
|
|
Point closept;
|
|
|
|
LINE tmp;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1998-09-01 06:40:42 +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-09-01 06:40:42 +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
|
|
|
|
*
|
|
|
|
* This sets the closest point to the *result if it is not NULL and returns
|
|
|
|
* the distance to the closest point.
|
1998-02-03 16:55:58 +01:00
|
|
|
*/
|
2018-07-29 02:02:48 +02:00
|
|
|
static float8
|
|
|
|
lseg_closept_lseg(Point *result, LSEG *l1, LSEG *l2)
|
1998-02-03 16:55:58 +01:00
|
|
|
{
|
|
|
|
Point point;
|
|
|
|
double dist;
|
2000-07-30 22:44:02 +02:00
|
|
|
double d;
|
1998-02-03 16:55:58 +01:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
d = lseg_closept_point(NULL, l1, &l2->p[0]);
|
2000-07-30 22:44:02 +02:00
|
|
|
dist = d;
|
2018-07-29 02:02:48 +02:00
|
|
|
if (result != NULL)
|
|
|
|
*result = l2->p[0];
|
1998-02-03 16:55:58 +01:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
d = lseg_closept_point(NULL, l1, &l2->p[1]);
|
|
|
|
if (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 = l2->p[1];
|
1998-02-03 16:55:58 +01:00
|
|
|
}
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
if (lseg_closept_point(&point, l2, &l1->p[0]) < dist)
|
|
|
|
d = lseg_closept_point(result, l1, &point);
|
1998-02-03 16:55:58 +01:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
if (lseg_closept_point(&point, l2, &l1->p[1]) < dist)
|
|
|
|
d = lseg_closept_point(result, l1, &point);
|
1998-02-03 16:55:58 +01:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
if (d < dist)
|
|
|
|
dist = d;
|
|
|
|
|
|
|
|
return dist;
|
|
|
|
}
|
|
|
|
|
|
|
|
Datum
|
|
|
|
close_lseg(PG_FUNCTION_ARGS)
|
|
|
|
{
|
|
|
|
LSEG *l1 = PG_GETARG_LSEG_P(0);
|
|
|
|
LSEG *l2 = PG_GETARG_LSEG_P(1);
|
|
|
|
Point *result;
|
|
|
|
|
|
|
|
result = (Point *) palloc(sizeof(Point));
|
|
|
|
|
|
|
|
lseg_closept_lseg(result, l2, l1);
|
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
|
|
|
*
|
|
|
|
* This sets the closest point to the *result if it is not NULL and returns
|
|
|
|
* the distance to the closest point.
|
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-07-29 02:02:48 +02:00
|
|
|
LSEG lseg;
|
|
|
|
Point point,
|
|
|
|
closept;
|
1998-02-03 16:55:58 +01:00
|
|
|
double dist,
|
2000-07-30 22:44:02 +02:00
|
|
|
d;
|
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);
|
|
|
|
if (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);
|
|
|
|
if (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);
|
|
|
|
if (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));
|
|
|
|
|
|
|
|
box_closept_point(result, box, pt);
|
|
|
|
|
|
|
|
PG_RETURN_POINT_P(result);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
1998-02-03 16:55:58 +01:00
|
|
|
/* close_sl()
|
|
|
|
* Closest point on line to line segment.
|
|
|
|
*
|
|
|
|
* XXX THIS CODE IS WRONG
|
|
|
|
* The code is actually calculating the point on the line segment
|
1998-02-26 05:46:47 +01:00
|
|
|
* which is backwards from the routine naming convention.
|
1998-02-03 16:55:58 +01:00
|
|
|
* Copied code to new routine close_ls() but haven't fixed this one yet.
|
|
|
|
* - thomas 1998-01-31
|
|
|
|
*/
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
close_sl(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2013-10-09 07:09:18 +02:00
|
|
|
#ifdef NOT_USED
|
2000-07-30 22:44:02 +02:00
|
|
|
LSEG *lseg = PG_GETARG_LSEG_P(0);
|
|
|
|
LINE *line = PG_GETARG_LINE_P(1);
|
1997-09-08 04:41:22 +02:00
|
|
|
Point *result;
|
2000-07-30 22:44:02 +02:00
|
|
|
float8 d1,
|
|
|
|
d2;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
result = (Point *) palloc(sizeof(Point));
|
|
|
|
|
|
|
|
if (lseg_interpt_line(result, lseg, line))
|
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
|
|
|
d1 = line_closept_point(NULL, line, &lseg->p[0]);
|
|
|
|
d2 = line_closept_point(NULL, line, &lseg->p[1]);
|
1997-09-07 07:04:48 +02:00
|
|
|
if (d1 < d2)
|
2018-07-29 02:02:48 +02:00
|
|
|
*result = lseg->p[0];
|
1997-09-07 07:04:48 +02:00
|
|
|
else
|
2018-07-29 02:02:48 +02:00
|
|
|
*result = lseg->p[1];
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_POINT_P(result);
|
2013-10-09 07:09:18 +02:00
|
|
|
#endif
|
|
|
|
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
|
|
|
errmsg("function \"close_sl\" not implemented")));
|
|
|
|
|
|
|
|
PG_RETURN_NULL();
|
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 line segment to line.
|
2018-07-29 02:02:48 +02:00
|
|
|
*
|
|
|
|
* This sets the closest point to the *result if it is not NULL and returns
|
|
|
|
* the distance to the closest point.
|
|
|
|
*
|
|
|
|
* NOTE: When the lines are parallel, endpoints of one of the line segment
|
|
|
|
* are FPeq(), in presence of NaN or Infinitive coordinates, or perhaps =
|
|
|
|
* 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-07-29 02:02:48 +02:00
|
|
|
result = (Point *) palloc(sizeof(Point));
|
1998-02-03 16:55:58 +01:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
lseg_closept_line(result, lseg, line);
|
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
|
|
|
*
|
|
|
|
* This sets the closest point to the *result if it is not NULL and returns
|
|
|
|
* the distance to the closest 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-07-29 02:02:48 +02:00
|
|
|
Point point,
|
|
|
|
closept;
|
|
|
|
LSEG bseg;
|
1998-02-03 16:55:58 +01:00
|
|
|
double dist,
|
|
|
|
d;
|
|
|
|
|
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);
|
|
|
|
if (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);
|
|
|
|
if (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);
|
|
|
|
if (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));
|
|
|
|
|
|
|
|
box_closept_lseg(result, box, lseg);
|
|
|
|
|
|
|
|
PG_RETURN_POINT_P(result);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
Datum
|
|
|
|
close_lb(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2000-07-30 22:44:02 +02:00
|
|
|
#ifdef NOT_USED
|
|
|
|
LINE *line = PG_GETARG_LINE_P(0);
|
|
|
|
BOX *box = PG_GETARG_BOX_P(1);
|
|
|
|
#endif
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* think about this one for a while */
|
2003-07-27 06:53:12 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
2003-09-25 08:58:07 +02:00
|
|
|
errmsg("function \"close_lb\" not implemented")));
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_NULL();
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*---------------------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* on_
|
|
|
|
* Whether one object lies completely within another.
|
1996-07-09 08:22:35 +02:00
|
|
|
*-------------------------------------------------------------------*/
|
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
/*
|
1997-09-07 07:04:48 +02:00
|
|
|
* Does the point satisfy the equation?
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
2018-07-29 02:02:48 +02:00
|
|
|
static bool
|
|
|
|
line_contain_point(LINE *line, Point *point)
|
|
|
|
{
|
|
|
|
return FPzero(line->A * point->x + line->B * point->y + line->C);
|
|
|
|
}
|
|
|
|
|
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
|
|
|
/*
|
1997-09-07 07:04:48 +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
|
2010-02-26 03:01:40 +01:00
|
|
|
box_contain_pt(PG_FUNCTION_ARGS)
|
2010-01-14 17:31:09 +01:00
|
|
|
{
|
|
|
|
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
|
|
|
}
|
|
|
|
|
1997-09-07 07:04:48 +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)
|
1997-09-07 07:04:48 +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)
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
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-09-08 04:41:22 +02:00
|
|
|
int i,
|
|
|
|
n;
|
|
|
|
double a,
|
|
|
|
b;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
1998-10-29 19:11:28 +01:00
|
|
|
/*-- OPEN --*/
|
1997-09-07 07:04:48 +02:00
|
|
|
if (!path->closed)
|
1998-10-29 19:11:28 +01:00
|
|
|
{
|
1997-09-07 07:04:48 +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]);
|
|
|
|
if (FPeq(a + b,
|
|
|
|
point_dt(&path->p[i], &path->p[i + 1])))
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_BOOL(true);
|
1997-09-07 07:04:48 +02:00
|
|
|
a = b;
|
|
|
|
}
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_BOOL(false);
|
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
|
|
|
|
|
|
|
/*---------------------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* inter_
|
|
|
|
* Whether one object intersects another.
|
1996-07-09 08:22:35 +02:00
|
|
|
*-------------------------------------------------------------------*/
|
|
|
|
|
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,
|
1998-02-26 05:46:47 +01:00
|
|
|
* try converting box to path first.
|
1998-02-03 16:55:58 +01:00
|
|
|
*
|
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
|
|
|
|
|
|
|
lbox.low.x = Min(lseg->p[0].x, lseg->p[1].x);
|
|
|
|
lbox.low.y = Min(lseg->p[0].y, lseg->p[1].y);
|
|
|
|
lbox.high.x = Max(lseg->p[0].x, lseg->p[1].x);
|
|
|
|
lbox.high.y = Max(lseg->p[0].y, lseg->p[1].y);
|
|
|
|
|
|
|
|
/* 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
|
1997-09-07 07:04:48 +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-09-07 07:04:48 +02:00
|
|
|
static void
|
1997-09-08 23:56:23 +02:00
|
|
|
make_bound_box(POLYGON *poly)
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
int i;
|
|
|
|
double x1,
|
|
|
|
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++)
|
|
|
|
{
|
|
|
|
if (poly->p[i].x < x1)
|
|
|
|
x1 = poly->p[i].x;
|
|
|
|
if (poly->p[i].x > x2)
|
|
|
|
x2 = poly->p[i].x;
|
|
|
|
if (poly->p[i].y < y1)
|
|
|
|
y1 = poly->p[i].y;
|
|
|
|
if (poly->p[i].y > y2)
|
|
|
|
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
|
|
|
|
*
|
1997-09-07 07:04:48 +02:00
|
|
|
* 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);
|
1997-09-08 04:41:22 +02:00
|
|
|
POLYGON *poly;
|
|
|
|
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
|
|
|
|
1997-09-07 07:04:48 +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;
|
2017-06-21 20:39:04 +02: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);
|
1997-09-07 07:04:48 +02:00
|
|
|
poly->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(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
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
make_bound_box(poly);
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_POLYGON_P(poly);
|
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
/*---------------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* poly_out - convert internal POLYGON representation to the
|
|
|
|
* 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
|
|
|
{
|
2001-03-22 05:01:46 +01: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);
|
2003-08-04 02:43:34 +02:00
|
|
|
POLYGON *poly;
|
2003-05-13 20:03:08 +02:00
|
|
|
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),
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +02:00
|
|
|
errmsg("invalid number of points in external \"polygon\" value")));
|
2003-05-13 20:03:08 +02:00
|
|
|
|
2017-06-21 20:39:04 +02: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)
|
|
|
|
{
|
2003-08-04 02:43:34 +02:00
|
|
|
POLYGON *poly = PG_GETARG_POLYGON_P(0);
|
2003-05-13 20:03:08 +02:00
|
|
|
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
|
|
|
{
|
2001-03-22 05:01:46 +01: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;
|
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Avoid leaking memory for toasted inputs ... needed for rtree indexes
|
2001-03-22 05:01:46 +01:00
|
|
|
*/
|
2000-12-09 00:57:03 +01:00
|
|
|
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
|
|
|
{
|
2001-03-22 05:01:46 +01: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
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Avoid leaking memory for toasted inputs ... needed for rtree indexes
|
2001-03-22 05:01:46 +01:00
|
|
|
*/
|
2000-12-09 00:57:03 +01:00
|
|
|
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
|
|
|
{
|
2001-03-22 05:01:46 +01: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;
|
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Avoid leaking memory for toasted inputs ... needed for rtree indexes
|
2001-03-22 05:01:46 +01:00
|
|
|
*/
|
2000-12-09 00:57:03 +01:00
|
|
|
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
|
|
|
{
|
2001-03-22 05:01:46 +01: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;
|
|
|
|
|
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Avoid leaking memory for toasted inputs ... needed for rtree indexes
|
2005-06-24 22:53:34 +02:00
|
|
|
*/
|
|
|
|
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
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Avoid leaking memory for toasted inputs ... needed for rtree indexes
|
2001-03-22 05:01:46 +01:00
|
|
|
*/
|
2000-12-09 00:57:03 +01:00
|
|
|
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;
|
|
|
|
|
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Avoid leaking memory for toasted inputs ... needed for rtree indexes
|
2005-06-24 22:53:34 +02:00
|
|
|
*/
|
|
|
|
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;
|
|
|
|
|
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Avoid leaking memory for toasted inputs ... needed for rtree indexes
|
2005-06-24 22:53:34 +02:00
|
|
|
*/
|
|
|
|
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;
|
|
|
|
|
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Avoid leaking memory for toasted inputs ... needed for rtree indexes
|
2005-06-24 22:53:34 +02:00
|
|
|
*/
|
|
|
|
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
|
1997-09-07 07:04:48 +02:00
|
|
|
* 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
|
|
|
{
|
2001-03-22 05:01:46 +01: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
|
|
|
|
1997-09-07 07:04:48 +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);
|
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Avoid leaking memory for toasted inputs ... needed for rtree indexes
|
2001-03-22 05:01:46 +01:00
|
|
|
*/
|
2000-12-09 00:57:03 +01:00
|
|
|
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
|
|
|
|
|
|
|
/*-----------------------------------------------------------------
|
2010-02-26 03:01:40 +01:00
|
|
|
* Determine if polygon A overlaps polygon B
|
1996-07-09 08:22:35 +02:00
|
|
|
*-----------------------------------------------------------------*/
|
2000-07-29 20:46:12 +02:00
|
|
|
Datum
|
|
|
|
poly_overlap(PG_FUNCTION_ARGS)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2001-03-22 05:01:46 +01: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
|
|
|
|
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
|
|
|
|
|
|
|
/*
|
2010-02-26 03:01:40 +01: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.
|
2009-07-28 11:48:00 +02:00
|
|
|
*/
|
|
|
|
if (result)
|
|
|
|
{
|
2010-02-26 03:01:40 +01:00
|
|
|
int ia,
|
|
|
|
ib;
|
|
|
|
LSEG sa,
|
|
|
|
sb;
|
2009-07-28 11:48:00 +02:00
|
|
|
|
|
|
|
/* 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
|
|
|
{
|
2010-02-26 03:01:40 +01:00
|
|
|
/* Second point of polya's edge is a current one */
|
2009-07-28 11:48:00 +02:00
|
|
|
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];
|
|
|
|
}
|
|
|
|
|
2010-02-26 03:01:40 +01:00
|
|
|
/*
|
|
|
|
* move current endpoint to the first point of next edge
|
2009-07-28 11:48:00 +02:00
|
|
|
*/
|
|
|
|
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) ||
|
2010-02-26 03:01:40 +01:00
|
|
|
point_inside(polyb->p, polya->npts, polya->p));
|
2009-07-28 11:48:00 +02:00
|
|
|
}
|
|
|
|
}
|
2000-12-09 00:57:03 +01:00
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Avoid leaking memory for toasted inputs ... needed for rtree indexes
|
2001-03-22 05:01:46 +01:00
|
|
|
*/
|
2000-12-09 00:57:03 +01:00
|
|
|
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:
|
2010-02-26 03:01:40 +01:00
|
|
|
* - point a should be on segment s
|
|
|
|
* - segment (a,b) should not be contained by s
|
2009-07-28 11:48:00 +02:00
|
|
|
* Returns true if:
|
2010-02-26 03:01:40 +01:00
|
|
|
* - 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!
|
|
|
|
*/
|
2009-07-28 11:48:00 +02:00
|
|
|
|
|
|
|
static bool
|
|
|
|
touched_lseg_inside_poly(Point *a, Point *b, LSEG *s, POLYGON *poly, int start)
|
|
|
|
{
|
|
|
|
/* point a is on s, b is not */
|
2010-02-26 03:01:40 +01:00
|
|
|
LSEG t;
|
2009-07-28 11:48:00 +02:00
|
|
|
|
|
|
|
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))
|
2010-02-26 03:01:40 +01:00
|
|
|
return lseg_inside_poly(b, s->p + 1, poly, start);
|
2009-07-28 11:48:00 +02:00
|
|
|
}
|
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
|
|
|
{
|
2010-02-26 03:01:40 +01:00
|
|
|
return lseg_inside_poly(b, s->p + 1, poly, start);
|
2009-07-28 11:48:00 +02:00
|
|
|
}
|
|
|
|
|
2010-02-26 03:01:40 +01:00
|
|
|
return true; /* may be not true, but that will check later */
|
2009-07-28 11:48:00 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Returns true if segment (a,b) is in polygon, option
|
2010-02-26 03:01:40 +01:00
|
|
|
* start is used for optimization - function checks
|
2009-07-28 11:48:00 +02:00
|
|
|
* polygon's edges started from start
|
|
|
|
*/
|
|
|
|
static bool
|
|
|
|
lseg_inside_poly(Point *a, Point *b, POLYGON *poly, int start)
|
|
|
|
{
|
2010-02-26 03:01:40 +01:00
|
|
|
LSEG s,
|
|
|
|
t;
|
|
|
|
int i;
|
|
|
|
bool res = true,
|
|
|
|
intersection = false;
|
2009-07-28 11:48:00 +02:00
|
|
|
|
|
|
|
t.p[0] = *a;
|
|
|
|
t.p[1] = *b;
|
2010-02-26 03:01:40 +01:00
|
|
|
s.p[0] = poly->p[(start == 0) ? (poly->npts - 1) : (start - 1)];
|
2009-07-28 11:48:00 +02:00
|
|
|
|
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))
|
2010-02-26 03:01:40 +01:00
|
|
|
return true; /* t is contained by s */
|
2009-07-28 11:48:00 +02:00
|
|
|
|
|
|
|
/* Y-cross */
|
2010-02-26 03:01:40 +01:00
|
|
|
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 */
|
2010-02-26 03:01:40 +01:00
|
|
|
res = touched_lseg_inside_poly(t.p + 1, t.p, &s, poly, i + 1);
|
2009-07-28 11:48:00 +02:00
|
|
|
}
|
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)
|
|
|
|
{
|
2010-02-26 03:01:40 +01:00
|
|
|
Point p;
|
2009-07-28 11:48:00 +02:00
|
|
|
|
|
|
|
/*
|
2010-02-26 03:01:40 +01:00
|
|
|
* if X-intersection wasn't found then check central point of tested
|
|
|
|
* segment. In opposite case we already check all subsegments
|
2009-07-28 11:48:00 +02:00
|
|
|
*/
|
2010-02-26 03:01:40 +01:00
|
|
|
p.x = (t.p[0].x + t.p[1].x) / 2.0;
|
2009-07-28 11:48:00 +02:00
|
|
|
p.y = (t.p[0].y + t.p[1].y) / 2.0;
|
|
|
|
|
2010-02-26 03:01:40 +01:00
|
|
|
res = point_inside(&p, poly->npts, poly->p);
|
2009-07-28 11:48:00 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
return res;
|
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
/*-----------------------------------------------------------------
|
2000-07-29 20:46:12 +02:00
|
|
|
* Determine if polygon A contains polygon B.
|
1996-07-09 08:22:35 +02:00
|
|
|
*-----------------------------------------------------------------*/
|
2018-07-29 02:02:48 +02:00
|
|
|
static bool
|
|
|
|
poly_contain_poly(POLYGON *polya, POLYGON *polyb)
|
1997-07-29 18:08:18 +02:00
|
|
|
{
|
2018-07-29 02:02:48 +02:00
|
|
|
int i;
|
|
|
|
LSEG s;
|
|
|
|
|
|
|
|
Assert(polya->npts > 0 && polyb->npts > 0);
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
/*
|
|
|
|
* Quick check to see if bounding box is contained.
|
|
|
|
*/
|
2018-07-29 02:02:48 +02:00
|
|
|
if (!box_contain_box(&polya->boundbox, &polyb->boundbox))
|
|
|
|
return false;
|
2009-07-28 11:48:00 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
s.p[0] = polyb->p[polyb->npts - 1];
|
2009-07-28 11:48:00 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
for (i = 0; i < polyb->npts; i++)
|
2000-12-09 00:57:03 +01:00
|
|
|
{
|
2018-07-29 02:02:48 +02:00
|
|
|
s.p[1] = polyb->p[i];
|
|
|
|
if (!lseg_inside_poly(s.p, s.p + 1, polya, 0))
|
|
|
|
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);
|
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* Avoid leaking memory for toasted inputs ... needed for rtree indexes
|
2001-03-22 05:01:46 +01:00
|
|
|
*/
|
2000-12-09 00:57:03 +01:00
|
|
|
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
|
|
|
{
|
2001-03-22 05:01:46 +01:00
|
|
|
POLYGON *poly = PG_GETARG_POLYGON_P(0);
|
2000-07-29 20:46:12 +02:00
|
|
|
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);
|
2001-03-22 05:01:46 +01:00
|
|
|
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
|
|
|
#ifdef NOT_USED
|
2001-03-22 05:01:46 +01:00
|
|
|
POLYGON *polya = PG_GETARG_POLYGON_P(0);
|
|
|
|
POLYGON *polyb = PG_GETARG_POLYGON_P(1);
|
2000-07-29 20:46:12 +02:00
|
|
|
#endif
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2003-07-27 06:53:12 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
2003-09-25 08:58:07 +02:00
|
|
|
errmsg("function \"poly_distance\" not implemented")));
|
1997-07-29 18:08:18 +02:00
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
/***********************************************************************
|
|
|
|
**
|
1997-09-07 07:04:48 +02:00
|
|
|
** Routines for 2D 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
|
|
|
**
|
|
|
|
***********************************************************************/
|
|
|
|
|
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,
|
|
|
|
pt1->x + pt2->x,
|
|
|
|
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);
|
1997-09-08 04:41:22 +02:00
|
|
|
Point *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
|
|
|
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,
|
|
|
|
pt1->x - pt2->x,
|
|
|
|
pt1->y - pt2->y);
|
|
|
|
}
|
|
|
|
|
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);
|
1997-09-08 04:41:22 +02:00
|
|
|
Point *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
|
|
|
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,
|
|
|
|
(pt1->x * pt2->x) - (pt1->y * pt2->y),
|
|
|
|
(pt1->x * pt2->y) + (pt1->y * pt2->x));
|
|
|
|
}
|
|
|
|
|
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);
|
1997-09-08 04:41:22 +02:00
|
|
|
Point *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
|
|
|
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
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
double 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-07-29 02:02:48 +02:00
|
|
|
div = (pt2->x * pt2->x) + (pt2->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
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
if (div == 0.0)
|
2003-07-27 06:53:12 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_DIVISION_BY_ZERO),
|
|
|
|
errmsg("division by zero")));
|
1997-08-22 01:57:00 +02:00
|
|
|
|
2018-07-29 02:02:48 +02:00
|
|
|
point_construct(result,
|
|
|
|
((pt1->x * pt2->x) + (pt1->y * pt2->y)) / div,
|
|
|
|
((pt2->x * pt1->y) - (pt2->y * pt1->x)) / div);
|
|
|
|
}
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
/***********************************************************************
|
|
|
|
**
|
1997-09-07 07:04:48 +02:00
|
|
|
** Routines for 2D boxes.
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data 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
|
|
|
|
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);
|
1997-09-08 04:41:22 +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);
|
1997-09-08 04:41:22 +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));
|
|
|
|
|
|
|
|
container->high.x = Max(box1->high.x, box2->high.x);
|
|
|
|
container->low.x = Min(box1->low.x, box2->low.x);
|
|
|
|
container->high.y = Max(box1->high.y, box2->high.y);
|
|
|
|
container->low.y = Min(box1->low.y, box2->low.y);
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
/***********************************************************************
|
|
|
|
**
|
1997-09-07 07:04:48 +02:00
|
|
|
** Routines for 2D paths.
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data 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()
|
|
|
|
* 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);
|
1997-09-08 04:41:22 +02:00
|
|
|
PATH *result;
|
2002-08-30 01:05:44 +02:00
|
|
|
int size,
|
|
|
|
base_size;
|
1997-09-08 04:41:22 +02:00
|
|
|
int i;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data 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
|
|
|
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);
|
2017-06-21 20:39:04 +02: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);
|
1997-09-07 07:04:48 +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
|
|
|
|
1997-09-07 07:04:48 +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;
|
|
|
|
}
|
|
|
|
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;
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data 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);
|
1997-09-08 04:41:22 +02:00
|
|
|
int i;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data 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-07 07:04:48 +02:00
|
|
|
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);
|
1997-09-08 04:41:22 +02:00
|
|
|
int i;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data 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-07 07:04:48 +02:00
|
|
|
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);
|
1997-09-08 04:41:22 +02:00
|
|
|
int i;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data 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-07 07:04:48 +02:00
|
|
|
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);
|
1997-09-08 04:41:22 +02:00
|
|
|
int i;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data 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-07 07:04:48 +02:00
|
|
|
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_center(PG_FUNCTION_ARGS)
|
1997-07-29 18:08:18 +02:00
|
|
|
{
|
2000-07-29 20:46:12 +02:00
|
|
|
#ifdef NOT_USED
|
|
|
|
PATH *path = PG_GETARG_PATH_P(0);
|
|
|
|
#endif
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2003-07-27 06:53:12 +02:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
|
2003-09-25 08:58:07 +02:00
|
|
|
errmsg("function \"path_center\" not implemented")));
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-29 20:46:12 +02:00
|
|
|
PG_RETURN_NULL();
|
|
|
|
}
|
1997-07-29 18:08:18 +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);
|
1997-09-08 04:41:22 +02:00
|
|
|
POLYGON *poly;
|
|
|
|
int size;
|
|
|
|
int i;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data 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
|
|
|
/* This is not very consistent --- other similar cases return NULL ... */
|
1997-09-07 07:04:48 +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.
|
|
|
|
*/
|
2017-06-21 20:39:04 +02: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);
|
1997-09-07 07:04:48 +02:00
|
|
|
poly->npts = 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-09-07 07:04:48 +02:00
|
|
|
for (i = 0; i < path->npts; i++)
|
|
|
|
{
|
|
|
|
poly->p[i].x = path->p[i].x;
|
|
|
|
poly->p[i].y = path->p[i].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
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
make_bound_box(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
|
|
|
|
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
|
|
|
/***********************************************************************
|
|
|
|
**
|
1997-09-07 07:04:48 +02:00
|
|
|
** Routines for 2D polygons.
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data 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
|
|
|
|
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
|
|
|
{
|
2001-03-22 05:01:46 +01: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
|
|
|
{
|
2001-03-22 05:01:46 +01: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
|
|
|
{
|
2001-03-22 05:01:46 +01:00
|
|
|
POLYGON *poly = PG_GETARG_POLYGON_P(0);
|
1997-09-08 04:41:22 +02:00
|
|
|
BOX *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
|
|
|
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);
|
1997-09-08 04:41:22 +02:00
|
|
|
POLYGON *poly;
|
|
|
|
int 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
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* map four corners of the box to a polygon */
|
2017-06-21 20:39:04 +02: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);
|
1997-09-07 07:04:48 +02:00
|
|
|
poly->npts = 4;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data 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-07 07:04:48 +02:00
|
|
|
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;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data 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(&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
|
|
|
{
|
2001-03-22 05:01:46 +01:00
|
|
|
POLYGON *poly = PG_GETARG_POLYGON_P(0);
|
1997-09-08 04:41:22 +02:00
|
|
|
PATH *path;
|
|
|
|
int size;
|
|
|
|
int i;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data 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
|
|
|
|
* smaller by a small constant.
|
|
|
|
*/
|
2017-06-21 20:39:04 +02: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);
|
1997-09-07 07:04:48 +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
|
|
|
|
1997-09-07 07:04:48 +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;
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data 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
|
|
|
/***********************************************************************
|
|
|
|
**
|
1997-09-07 07:04:48 +02:00
|
|
|
** Routines for 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
|
|
|
**
|
|
|
|
***********************************************************************/
|
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
|
|
|
* Formatting and conversion routines.
|
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* circle_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
|
|
|
*
|
1997-09-07 07:04:48 +02:00
|
|
|
* External format: (center and radius of circle)
|
|
|
|
* "((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)
|
1997-09-07 07:04:48 +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));
|
1997-09-08 04:41:22 +02:00
|
|
|
char *s,
|
|
|
|
*cp;
|
|
|
|
int depth = 0;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
|
|
|
s = str;
|
2000-12-03 21:45:40 +01:00
|
|
|
while (isspace((unsigned char) *s))
|
1997-09-07 07:04:48 +02:00
|
|
|
s++;
|
|
|
|
if ((*s == LDELIM_C) || (*s == LDELIM))
|
|
|
|
{
|
|
|
|
depth++;
|
|
|
|
cp = (s + 1);
|
2000-12-03 21:45:40 +01:00
|
|
|
while (isspace((unsigned char) *cp))
|
1997-09-07 07:04:48 +02:00
|
|
|
cp++;
|
|
|
|
if (*cp == LDELIM)
|
|
|
|
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
|
|
|
|
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
|
|
|
|
|
|
|
if (*s == DELIM)
|
|
|
|
s++;
|
|
|
|
|
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);
|
|
|
|
if (circle->radius < 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
|
|
|
|
|
|
|
while (depth > 0)
|
|
|
|
{
|
2018-07-29 02:02:48 +02:00
|
|
|
if ((*s == RDELIM) || ((*s == RDELIM_C) && (depth == 1)))
|
1997-09-07 07:04:48 +02:00
|
|
|
{
|
|
|
|
depth--;
|
|
|
|
s++;
|
2000-12-03 21:45:40 +01:00
|
|
|
while (isspace((unsigned char) *s))
|
1997-09-07 07:04:48 +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
|
|
|
|
1997-09-07 07:04:48 +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
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* circle_out - convert a circle to external 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
|
|
|
*/
|
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);
|
|
|
|
|
|
|
|
if (circle->radius < 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
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* Relational operators for CIRCLEs.
|
|
|
|
* <, >, <=, >=, and == are based on circle area.
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data 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-07 07:04:48 +02:00
|
|
|
/* circles identical?
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data 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);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(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
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* circle_overlap - does circle1 overlap 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_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),
|
|
|
|
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
|
1997-09-07 07:04:48 +02:00
|
|
|
* the right edge of 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_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);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPle((circle1->center.x + circle1->radius),
|
|
|
|
(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
|
|
|
}
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* circle_left - is circle1 strictly left of 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_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);
|
|
|
|
|
2005-06-24 22:53:34 +02:00
|
|
|
PG_RETURN_BOOL(FPlt((circle1->center.x + circle1->radius),
|
2000-07-30 22:44:02 +02:00
|
|
|
(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
|
|
|
}
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* circle_right - is circle1 strictly right of 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_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);
|
|
|
|
|
2005-06-24 22:53:34 +02:00
|
|
|
PG_RETURN_BOOL(FPgt((circle1->center.x - circle1->radius),
|
2000-07-30 22:44:02 +02:00
|
|
|
(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
|
1997-09-07 07:04:48 +02:00
|
|
|
* the left edge of 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_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);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPge((circle1->center.x - circle1->radius),
|
|
|
|
(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
|
|
|
}
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* circle_contained - is circle1 contained by 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_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),
|
|
|
|
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
|
|
|
}
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* circle_contain - does circle1 contain 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_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),
|
|
|
|
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);
|
|
|
|
|
2005-07-01 21:19:05 +02:00
|
|
|
PG_RETURN_BOOL(FPlt((circle1->center.y + circle1->radius),
|
|
|
|
(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);
|
|
|
|
|
2005-07-01 21:19:05 +02:00
|
|
|
PG_RETURN_BOOL(FPgt((circle1->center.y - circle1->radius),
|
|
|
|
(circle2->center.y + circle2->radius)));
|
|
|
|
}
|
|
|
|
|
|
|
|
/* 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);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPle((circle1->center.y + circle1->radius),
|
|
|
|
(circle2->center.y + circle2->radius)));
|
|
|
|
}
|
|
|
|
|
|
|
|
/* 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);
|
|
|
|
|
|
|
|
PG_RETURN_BOOL(FPge((circle1->center.y - circle1->radius),
|
|
|
|
(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
|
|
|
}
|
|
|
|
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* circle_relop - is area(circle1) relop area(circle2), within
|
|
|
|
* our accuracy constraint?
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data 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_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
|
|
|
|
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* "Arithmetic" operators on 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
|
|
|
*---------------------------------------------------------*/
|
|
|
|
|
|
|
|
/* 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);
|
1997-09-08 04:41:22 +02:00
|
|
|
CIRCLE *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 = (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);
|
1997-09-08 04:41:22 +02:00
|
|
|
CIRCLE *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 = (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);
|
1997-09-08 04:41:22 +02:00
|
|
|
CIRCLE *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 = (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);
|
|
|
|
result->radius = 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);
|
1997-09-08 04:41:22 +02:00
|
|
|
CIRCLE *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 = (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);
|
|
|
|
result->radius = 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
|
|
|
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* circle_area - returns the area of the 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
|
|
|
*/
|
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
|
|
|
}
|
|
|
|
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* circle_diameter - returns the diameter of the 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
|
|
|
*/
|
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
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
PG_RETURN_FLOAT8(2 * 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-09-07 07:04:48 +02:00
|
|
|
/* circle_radius - returns the radius of the 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
|
|
|
*/
|
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-09-07 07:04:48 +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-07-29 02:02:48 +02:00
|
|
|
result = point_dt(&circle1->center, &circle2->center) -
|
|
|
|
(circle1->radius + circle2->radius);
|
2000-07-30 22:44:02 +02:00
|
|
|
if (result < 0)
|
|
|
|
result = 0;
|
|
|
|
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);
|
|
|
|
double 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);
|
|
|
|
double d;
|
|
|
|
|
|
|
|
d = point_dt(&circle->center, point);
|
|
|
|
PG_RETURN_BOOL(d <= circle->radius);
|
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* dist_pc - returns the distance between
|
|
|
|
* a point and a circle.
|
1997-04-25 20:40:50 +02:00
|
|
|
*/
|
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
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
result = point_dt(point, &circle->center) - circle->radius;
|
|
|
|
if (result < 0)
|
|
|
|
result = 0;
|
|
|
|
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;
|
|
|
|
|
|
|
|
result = point_dt(point, &circle->center) - circle->radius;
|
|
|
|
if (result < 0)
|
|
|
|
result = 0;
|
|
|
|
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
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* circle_center - returns the center point of the 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
|
|
|
*/
|
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);
|
1997-09-08 04:41:22 +02:00
|
|
|
Point *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
|
|
|
result = (Point *) palloc(sizeof(Point));
|
1997-09-07 07:04:48 +02:00
|
|
|
result->x = circle->center.x;
|
|
|
|
result->y = circle->center.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_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
|
|
|
}
|
|
|
|
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
/* circle_ar - returns the area of the 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
|
|
|
*/
|
1997-09-07 07:04:48 +02:00
|
|
|
static double
|
1997-09-08 23:56:23 +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
|
|
|
{
|
2002-11-08 19:32:47 +01:00
|
|
|
return M_PI * (circle->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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*----------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* Conversion 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-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);
|
1997-09-08 04:41:22 +02:00
|
|
|
CIRCLE *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
|
|
|
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
|
|
|
|
1997-09-07 07:04:48 +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-09-08 04:41:22 +02:00
|
|
|
BOX *box;
|
|
|
|
double 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
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
delta = circle->radius / sqrt(2.0);
|
1997-07-29 18:08:18 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
box->high.x = circle->center.x + delta;
|
|
|
|
box->low.x = circle->center.x - delta;
|
|
|
|
box->high.y = circle->center.y + delta;
|
|
|
|
box->low.y = 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-09-08 04:41:22 +02:00
|
|
|
CIRCLE *circle;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
2000-07-30 22:44:02 +02:00
|
|
|
circle = (CIRCLE *) palloc(sizeof(CIRCLE));
|
1997-07-29 18:08:18 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
circle->center.x = (box->high.x + box->low.x) / 2;
|
|
|
|
circle->center.y = (box->high.y + box->low.y) / 2;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
circle->radius = point_dt(&circle->center, &box->high);
|
1997-07-29 18:08:18 +02:00
|
|
|
|
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);
|
1997-09-08 04:41:22 +02:00
|
|
|
POLYGON *poly;
|
2002-08-30 01:05:44 +02:00
|
|
|
int base_size,
|
|
|
|
size;
|
1997-09-08 04:41:22 +02:00
|
|
|
int i;
|
|
|
|
double angle;
|
2002-11-08 19:32:47 +01:00
|
|
|
double 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),
|
Phase 3 of pgindent updates.
Don't move parenthesized lines to the left, even if that means they
flow past the right margin.
By default, BSD indent lines up statement continuation lines that are
within parentheses so that they start just to the right of the preceding
left parenthesis. However, traditionally, if that resulted in the
continuation line extending to the right of the desired right margin,
then indent would push it left just far enough to not overrun the margin,
if it could do so without making the continuation line start to the left of
the current statement indent. That makes for a weird mix of indentations
unless one has been completely rigid about never violating the 80-column
limit.
This behavior has been pretty universally panned by Postgres developers.
Hence, disable it with indent's new -lpl switch, so that parenthesized
lines are always lined up with the preceding left paren.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:35:54 +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;
|
2017-06-21 20:39:04 +02: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);
|
1997-09-07 07:04:48 +02:00
|
|
|
poly->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
|
|
|
|
2002-11-08 19:32:47 +01:00
|
|
|
anglestep = (2.0 * M_PI) / npts;
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
for (i = 0; i < npts; i++)
|
|
|
|
{
|
2002-11-08 19:32:47 +01:00
|
|
|
angle = i * anglestep;
|
1997-09-07 07:04:48 +02:00
|
|
|
poly->p[i].x = circle->center.x - (circle->radius * cos(angle));
|
|
|
|
poly->p[i].y = circle->center.y + (circle->radius * sin(angle));
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data 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-07 07:04:48 +02:00
|
|
|
make_bound_box(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
|
|
|
|
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
|
1997-09-07 07:04:48 +02:00
|
|
|
* rather than straight average values of points - tgl 97/01/21.
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data 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 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
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
int i;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data 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
|
|
|
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
|
|
|
|
1997-09-07 07:04:48 +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]);
|
|
|
|
result->center.x /= poly->npts;
|
|
|
|
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
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
for (i = 0; i < poly->npts; i++)
|
2018-07-29 02:02:48 +02:00
|
|
|
result->radius += point_dt(&poly->p[i], &result->center);
|
|
|
|
result->radius /= 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
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
/***********************************************************************
|
|
|
|
**
|
1997-09-07 07:04:48 +02:00
|
|
|
** Private routines for multiple types.
|
1997-07-29 18:08:18 +02:00
|
|
|
**
|
|
|
|
***********************************************************************/
|
|
|
|
|
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
|
1998-09-01 05:29:17 +02:00
|
|
|
point_inside(Point *p, int npts, Point *plist)
|
1997-07-29 18:08:18 +02:00
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
double x0,
|
|
|
|
y0;
|
2007-03-06 00:29:14 +01:00
|
|
|
double prev_x,
|
|
|
|
prev_y;
|
|
|
|
int i = 0;
|
1997-09-08 04:41:22 +02:00
|
|
|
double x,
|
|
|
|
y;
|
2007-11-15 22:14:46 +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 */
|
1997-09-07 07:04:48 +02:00
|
|
|
x0 = plist[0].x - p->x;
|
|
|
|
y0 = 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-09-07 07:04:48 +02:00
|
|
|
for (i = 1; i < npts; i++)
|
|
|
|
{
|
2007-03-06 00:29:14 +01:00
|
|
|
/* compute next polygon point relative to single point */
|
1997-09-07 07:04:48 +02:00
|
|
|
x = plist[i].x - p->x;
|
|
|
|
y = 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-09-07 07:04:48 +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-09-07 07:04:48 +02:00
|
|
|
return 2;
|
2007-03-06 00:29:14 +01:00
|
|
|
total_cross += cross;
|
|
|
|
|
|
|
|
if (total_cross != 0)
|
1997-09-07 07:04:48 +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
|
2007-03-06 00:29:14 +01:00
|
|
|
lseg_crossing(double x, double y, double prev_x, double prev_y)
|
1997-07-29 18:08:18 +02:00
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
double z;
|
2007-03-06 00:29:14 +01:00
|
|
|
int y_sign;
|
1997-07-29 18:08:18 +02:00
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
if (FPzero(y))
|
2007-11-15 22:14:46 +01:00
|
|
|
{ /* y == 0, on X axis */
|
|
|
|
if (FPzero(x)) /* (x,y) is (0,0)? */
|
2007-03-06 00:29:14 +01:00
|
|
|
return POINT_ON_POLYGON;
|
1997-09-07 07:04:48 +02:00
|
|
|
else if (FPgt(x, 0))
|
2007-11-15 22:14:46 +01:00
|
|
|
{ /* x > 0 */
|
|
|
|
if (FPzero(prev_y)) /* y and prev_y are zero */
|
2007-03-06 00:29:14 +01:00
|
|
|
/* prev_x > 0? */
|
|
|
|
return FPgt(prev_x, 0) ? 0 : POINT_ON_POLYGON;
|
|
|
|
return FPlt(prev_y, 0) ? 1 : -1;
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
else
|
2007-11-15 22:14:46 +01:00
|
|
|
{ /* x < 0, x not on positive X axis */
|
2007-03-06 00:29:14 +01:00
|
|
|
if (FPzero(prev_y))
|
|
|
|
/* prev_x < 0? */
|
|
|
|
return FPlt(prev_x, 0) ? 0 : POINT_ON_POLYGON;
|
1998-09-01 05:29:17 +02:00
|
|
|
return 0;
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
1997-09-05 20:13:45 +02:00
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
else
|
2007-11-15 22:14:46 +01:00
|
|
|
{ /* y != 0 */
|
2007-03-06 00:29:14 +01:00
|
|
|
/* compute y crossing direction from previous point */
|
|
|
|
y_sign = FPgt(y, 0) ? 1 : -1;
|
|
|
|
|
|
|
|
if (FPzero(prev_y))
|
|
|
|
/* previous point was on X axis, so new point is either off or on */
|
|
|
|
return FPlt(prev_x, 0) ? 0 : y_sign;
|
|
|
|
else if (FPgt(y_sign * prev_y, 0))
|
|
|
|
/* both above or below X axis */
|
2007-11-15 22:14:46 +01:00
|
|
|
return 0; /* same sign */
|
2007-03-06 00:29:14 +01:00
|
|
|
else
|
2007-11-15 22:14:46 +01:00
|
|
|
{ /* y and prev_y cross X-axis */
|
2007-03-06 00:29:14 +01:00
|
|
|
if (FPge(x, 0) && FPgt(prev_x, 0))
|
|
|
|
/* both non-negative so cross positive X-axis */
|
|
|
|
return 2 * y_sign;
|
|
|
|
if (FPlt(x, 0) && FPle(prev_x, 0))
|
|
|
|
/* both non-positive so do not cross positive X-axis */
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/* x and y cross axises, see URL above point_inside() */
|
|
|
|
z = (x - prev_x) * y - (y - prev_y) * x;
|
|
|
|
if (FPzero(z))
|
|
|
|
return POINT_ON_POLYGON;
|
|
|
|
return FPgt((y_sign * z), 0) ? 0 : 2 * y_sign;
|
|
|
|
}
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
2000-07-30 22:44:02 +02:00
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
|
|
|
|
|
1997-09-08 04:41:22 +02:00
|
|
|
static bool
|
1998-09-01 05:29:17 +02:00
|
|
|
plist_same(int npts, Point *p1, Point *p2)
|
1997-07-29 18:08:18 +02:00
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
int i,
|
|
|
|
ii,
|
|
|
|
j;
|
1997-09-07 07:04:48 +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-09-07 07:04:48 +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-09-07 07:04:48 +02:00
|
|
|
{
|
1997-07-29 18:08:18 +02:00
|
|
|
#ifdef GEODEBUG
|
1997-09-07 07:04:48 +02:00
|
|
|
printf("plist_same- %d failed forward match with %d\n", j, ii);
|
1997-07-29 18:08:18 +02:00
|
|
|
#endif
|
1997-09-07 07:04:48 +02:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
#ifdef GEODEBUG
|
1997-09-07 07:04:48 +02:00
|
|
|
printf("plist_same- ii = %d/%d after forward match\n", ii, npts);
|
1997-07-29 18:08:18 +02:00
|
|
|
#endif
|
1997-09-07 07:04:48 +02:00
|
|
|
if (ii == npts)
|
2017-08-16 06:22:32 +02:00
|
|
|
return true;
|
1997-09-07 07:04:48 +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-09-07 07:04:48 +02:00
|
|
|
{
|
1997-07-29 18:08:18 +02:00
|
|
|
#ifdef GEODEBUG
|
1997-09-07 07:04:48 +02:00
|
|
|
printf("plist_same- %d failed reverse match with %d\n", j, ii);
|
1997-07-29 18:08:18 +02:00
|
|
|
#endif
|
1997-09-07 07:04:48 +02:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
1997-07-29 18:08:18 +02:00
|
|
|
#ifdef GEODEBUG
|
1997-09-07 07:04:48 +02:00
|
|
|
printf("plist_same- ii = %d/%d after reverse match\n", ii, npts);
|
1997-07-29 18:08:18 +02:00
|
|
|
#endif
|
1997-09-07 07:04:48 +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.
|
|
|
|
*-----------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
double
|
|
|
|
pg_hypot(double x, double y)
|
|
|
|
{
|
|
|
|
double yx;
|
|
|
|
|
|
|
|
/* 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)
|
|
|
|
{
|
|
|
|
double temp = x;
|
|
|
|
|
|
|
|
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;
|
|
|
|
return x * sqrt(1.0 + (yx * yx));
|
|
|
|
}
|