1996-08-28 03:59:28 +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
|
|
|
* geo_decls.h - Declarations for various 2D constructs.
|
1996-08-28 03:59:28 +02:00
|
|
|
*
|
|
|
|
*
|
2023-01-02 21:00:37 +01:00
|
|
|
* Portions Copyright (c) 1996-2023, PostgreSQL Global Development Group
|
2000-01-26 06:58:53 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
1996-08-28 03:59:28 +02:00
|
|
|
*
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/include/utils/geo_decls.h
|
1996-08-28 03:59:28 +02:00
|
|
|
*
|
|
|
|
* XXX These routines were not written by a numerical analyst.
|
2000-02-17 04:40:02 +01:00
|
|
|
*
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
* XXX I have made some attempt to flesh out the operators
|
|
|
|
* and data types. There are still some more to do. - tgl 97/04/19
|
1996-08-28 03:59:28 +02:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
#ifndef GEO_DECLS_H
|
|
|
|
#define GEO_DECLS_H
|
|
|
|
|
Fix FPeq() and friends to get the right answers for infinities.
"FPeq(infinity, infinity)" returned false, on account of getting NaN
when it subtracts the two inputs. Fix that by adding a separate
check for exact equality.
FPle() and FPge() similarly got the wrong answer for two like-signed
infinities. In those cases, we can just rearrange the comparisons
to avoid potentially subtracting infinities.
While the sibling functions FPne() etc accidentally gave the right
answers even with the internal NaN results, it seems best to make
similar adjustments to them to avoid depending on this.
FPeq() has to be converted to an inline function to avoid double
evaluations of its arguments, and I did the same for the others
just for consistency.
In passing, make the handling of NaN cases in line_eq() and
point_eq_point() simpler and easier to reason about, and perhaps
faster.
This results in just one visible regression test change: slope()
now gives DBL_MAX for two inputs of (inf,1e300), which is consistent
with what it does for (1e300,inf), so that seems like a bug fix.
Discussion: https://postgr.es/m/CAGf+fX70rWFOk5cd00uMfa__0yP+vtQg5ck7c2Onb-Yczp0URA@mail.gmail.com
2020-11-21 22:46:43 +01:00
|
|
|
#include <math.h>
|
|
|
|
|
2000-06-05 09:29:25 +02:00
|
|
|
#include "fmgr.h"
|
1996-11-10 04:06:38 +01:00
|
|
|
|
1996-08-28 03:59:28 +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
|
|
|
* Useful floating point utilities and constants.
|
Fix FPeq() and friends to get the right answers for infinities.
"FPeq(infinity, infinity)" returned false, on account of getting NaN
when it subtracts the two inputs. Fix that by adding a separate
check for exact equality.
FPle() and FPge() similarly got the wrong answer for two like-signed
infinities. In those cases, we can just rearrange the comparisons
to avoid potentially subtracting infinities.
While the sibling functions FPne() etc accidentally gave the right
answers even with the internal NaN results, it seems best to make
similar adjustments to them to avoid depending on this.
FPeq() has to be converted to an inline function to avoid double
evaluations of its arguments, and I did the same for the others
just for consistency.
In passing, make the handling of NaN cases in line_eq() and
point_eq_point() simpler and easier to reason about, and perhaps
faster.
This results in just one visible regression test change: slope()
now gives DBL_MAX for two inputs of (inf,1e300), which is consistent
with what it does for (1e300,inf), so that seems like a bug fix.
Discussion: https://postgr.es/m/CAGf+fX70rWFOk5cd00uMfa__0yP+vtQg5ck7c2Onb-Yczp0URA@mail.gmail.com
2020-11-21 22:46:43 +01:00
|
|
|
*--------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* "Fuzzy" floating-point comparisons: values within EPSILON of each other
|
|
|
|
* are considered equal. Beware of normal reasoning about the behavior of
|
|
|
|
* these comparisons, since for example FPeq does not behave transitively.
|
|
|
|
*
|
|
|
|
* Note that these functions are not NaN-aware and will give FALSE for
|
|
|
|
* any case involving NaN inputs.
|
2018-08-16 19:56:11 +02:00
|
|
|
*
|
Fix FPeq() and friends to get the right answers for infinities.
"FPeq(infinity, infinity)" returned false, on account of getting NaN
when it subtracts the two inputs. Fix that by adding a separate
check for exact equality.
FPle() and FPge() similarly got the wrong answer for two like-signed
infinities. In those cases, we can just rearrange the comparisons
to avoid potentially subtracting infinities.
While the sibling functions FPne() etc accidentally gave the right
answers even with the internal NaN results, it seems best to make
similar adjustments to them to avoid depending on this.
FPeq() has to be converted to an inline function to avoid double
evaluations of its arguments, and I did the same for the others
just for consistency.
In passing, make the handling of NaN cases in line_eq() and
point_eq_point() simpler and easier to reason about, and perhaps
faster.
This results in just one visible regression test change: slope()
now gives DBL_MAX for two inputs of (inf,1e300), which is consistent
with what it does for (1e300,inf), so that seems like a bug fix.
Discussion: https://postgr.es/m/CAGf+fX70rWFOk5cd00uMfa__0yP+vtQg5ck7c2Onb-Yczp0URA@mail.gmail.com
2020-11-21 22:46:43 +01:00
|
|
|
* Also note that these will give sane answers for infinite inputs,
|
|
|
|
* where it's important to avoid computing Inf minus Inf; we do so
|
|
|
|
* by eliminating equality cases before subtracting.
|
2018-08-16 19:56:11 +02:00
|
|
|
*/
|
1996-08-28 03:59:28 +02:00
|
|
|
|
|
|
|
#define EPSILON 1.0E-06
|
|
|
|
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
#ifdef EPSILON
|
1996-08-28 03:59:28 +02:00
|
|
|
#define FPzero(A) (fabs(A) <= EPSILON)
|
Fix FPeq() and friends to get the right answers for infinities.
"FPeq(infinity, infinity)" returned false, on account of getting NaN
when it subtracts the two inputs. Fix that by adding a separate
check for exact equality.
FPle() and FPge() similarly got the wrong answer for two like-signed
infinities. In those cases, we can just rearrange the comparisons
to avoid potentially subtracting infinities.
While the sibling functions FPne() etc accidentally gave the right
answers even with the internal NaN results, it seems best to make
similar adjustments to them to avoid depending on this.
FPeq() has to be converted to an inline function to avoid double
evaluations of its arguments, and I did the same for the others
just for consistency.
In passing, make the handling of NaN cases in line_eq() and
point_eq_point() simpler and easier to reason about, and perhaps
faster.
This results in just one visible regression test change: slope()
now gives DBL_MAX for two inputs of (inf,1e300), which is consistent
with what it does for (1e300,inf), so that seems like a bug fix.
Discussion: https://postgr.es/m/CAGf+fX70rWFOk5cd00uMfa__0yP+vtQg5ck7c2Onb-Yczp0URA@mail.gmail.com
2020-11-21 22:46:43 +01:00
|
|
|
|
|
|
|
static inline bool
|
|
|
|
FPeq(double A, double B)
|
|
|
|
{
|
|
|
|
return A == B || fabs(A - B) <= EPSILON;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline bool
|
|
|
|
FPne(double A, double B)
|
|
|
|
{
|
|
|
|
return A != B && fabs(A - B) > EPSILON;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline bool
|
|
|
|
FPlt(double A, double B)
|
|
|
|
{
|
|
|
|
return A + EPSILON < B;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline bool
|
|
|
|
FPle(double A, double B)
|
|
|
|
{
|
|
|
|
return A <= B + EPSILON;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline bool
|
|
|
|
FPgt(double A, double B)
|
|
|
|
{
|
|
|
|
return A > B + EPSILON;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline bool
|
|
|
|
FPge(double A, double B)
|
|
|
|
{
|
|
|
|
return A + EPSILON >= B;
|
|
|
|
}
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
#else
|
2000-07-30 22:44:02 +02:00
|
|
|
#define FPzero(A) ((A) == 0)
|
|
|
|
#define FPeq(A,B) ((A) == (B))
|
|
|
|
#define FPne(A,B) ((A) != (B))
|
|
|
|
#define FPlt(A,B) ((A) < (B))
|
|
|
|
#define FPle(A,B) ((A) <= (B))
|
|
|
|
#define FPgt(A,B) ((A) > (B))
|
|
|
|
#define FPge(A,B) ((A) >= (B))
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
#endif
|
1996-08-28 03:59:28 +02:00
|
|
|
|
2010-08-03 23:21:03 +02:00
|
|
|
#define HYPOT(A, B) pg_hypot(A, B)
|
1996-08-28 03:59:28 +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
|
|
|
* Point - (x,y)
|
1996-08-28 03:59:28 +02:00
|
|
|
*-------------------------------------------------------------------*/
|
|
|
|
typedef struct
|
|
|
|
{
|
2018-08-16 19:56:11 +02:00
|
|
|
float8 x,
|
1996-08-28 03:59:28 +02:00
|
|
|
y;
|
|
|
|
} 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
|
|
|
* LSEG - A straight line, specified by endpoints.
|
1996-08-28 03:59:28 +02:00
|
|
|
*-------------------------------------------------------------------*/
|
|
|
|
typedef struct
|
|
|
|
{
|
|
|
|
Point p[2];
|
|
|
|
} LSEG;
|
|
|
|
|
|
|
|
|
|
|
|
/*---------------------------------------------------------------------
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data 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 - Specified by vertex points.
|
1996-08-28 03:59:28 +02:00
|
|
|
*-------------------------------------------------------------------*/
|
|
|
|
typedef struct
|
|
|
|
{
|
2007-02-28 00:48:10 +01:00
|
|
|
int32 vl_len_; /* varlena header (do not touch directly!) */
|
1996-08-28 03:59:28 +02:00
|
|
|
int32 npts;
|
|
|
|
int32 closed; /* is this a closed polygon? */
|
|
|
|
int32 dummy; /* padding to make it double align */
|
2015-02-20 06:11:42 +01:00
|
|
|
Point p[FLEXIBLE_ARRAY_MEMBER];
|
1996-08-28 03:59:28 +02:00
|
|
|
} 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
|
|
|
* LINE - Specified by its general equation (Ax+By+C=0).
|
1996-08-28 03:59:28 +02:00
|
|
|
*-------------------------------------------------------------------*/
|
|
|
|
typedef struct
|
|
|
|
{
|
2018-08-16 19:56:11 +02:00
|
|
|
float8 A,
|
1996-08-28 03:59:28 +02:00
|
|
|
B,
|
|
|
|
C;
|
|
|
|
} LINE;
|
|
|
|
|
|
|
|
|
|
|
|
/*---------------------------------------------------------------------
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
* BOX - Specified by two corner points, which are
|
|
|
|
* sorted to save calculation time later.
|
1996-08-28 03:59:28 +02:00
|
|
|
*-------------------------------------------------------------------*/
|
|
|
|
typedef struct
|
|
|
|
{
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
Point high,
|
|
|
|
low; /* corner POINTs */
|
1996-08-28 03:59:28 +02:00
|
|
|
} 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
|
|
|
* POLYGON - Specified by an array of doubles defining the points,
|
|
|
|
* keeping the number of points and the bounding box for
|
|
|
|
* speed purposes.
|
1996-08-28 03:59:28 +02:00
|
|
|
*-------------------------------------------------------------------*/
|
|
|
|
typedef struct
|
|
|
|
{
|
2007-02-28 00:48:10 +01:00
|
|
|
int32 vl_len_; /* varlena header (do not touch directly!) */
|
1996-08-28 03:59:28 +02:00
|
|
|
int32 npts;
|
|
|
|
BOX boundbox;
|
2015-02-20 06:11:42 +01:00
|
|
|
Point p[FLEXIBLE_ARRAY_MEMBER];
|
1996-08-28 03:59:28 +02:00
|
|
|
} 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
|
|
|
/*---------------------------------------------------------------------
|
|
|
|
* CIRCLE - Specified by a center point and radius.
|
|
|
|
*-------------------------------------------------------------------*/
|
|
|
|
typedef struct
|
|
|
|
{
|
|
|
|
Point center;
|
2018-08-16 19:56:11 +02:00
|
|
|
float8 radius;
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data type from "circle" to "widget" to keep the test from
trashing the new builtin circle type.
1997-04-22 19:35:09 +02:00
|
|
|
} CIRCLE;
|
1996-08-28 03:59:28 +02:00
|
|
|
|
2000-06-13 09:35:40 +02:00
|
|
|
/*
|
2022-09-27 20:47:07 +02:00
|
|
|
* fmgr interface functions
|
2000-06-13 09:35:40 +02:00
|
|
|
*
|
|
|
|
* Path and Polygon are toastable varlena types, the others are just
|
|
|
|
* fixed-size pass-by-reference types.
|
|
|
|
*/
|
|
|
|
|
2022-09-27 20:47:07 +02:00
|
|
|
static inline Point *
|
|
|
|
DatumGetPointP(Datum X)
|
|
|
|
{
|
|
|
|
return (Point *) DatumGetPointer(X);
|
|
|
|
}
|
|
|
|
static inline Datum
|
|
|
|
PointPGetDatum(const Point *X)
|
|
|
|
{
|
|
|
|
return PointerGetDatum(X);
|
|
|
|
}
|
2000-06-13 09:35:40 +02:00
|
|
|
#define PG_GETARG_POINT_P(n) DatumGetPointP(PG_GETARG_DATUM(n))
|
|
|
|
#define PG_RETURN_POINT_P(x) return PointPGetDatum(x)
|
|
|
|
|
2022-09-27 20:47:07 +02:00
|
|
|
static inline LSEG *
|
|
|
|
DatumGetLsegP(Datum X)
|
|
|
|
{
|
|
|
|
return (LSEG *) DatumGetPointer(X);
|
|
|
|
}
|
|
|
|
static inline Datum
|
|
|
|
LsegPGetDatum(const LSEG *X)
|
|
|
|
{
|
|
|
|
return PointerGetDatum(X);
|
|
|
|
}
|
2000-06-13 09:35:40 +02:00
|
|
|
#define PG_GETARG_LSEG_P(n) DatumGetLsegP(PG_GETARG_DATUM(n))
|
|
|
|
#define PG_RETURN_LSEG_P(x) return LsegPGetDatum(x)
|
|
|
|
|
2022-09-27 20:47:07 +02:00
|
|
|
static inline PATH *
|
|
|
|
DatumGetPathP(Datum X)
|
|
|
|
{
|
|
|
|
return (PATH *) PG_DETOAST_DATUM(X);
|
|
|
|
}
|
|
|
|
static inline PATH *
|
|
|
|
DatumGetPathPCopy(Datum X)
|
|
|
|
{
|
|
|
|
return (PATH *) PG_DETOAST_DATUM_COPY(X);
|
|
|
|
}
|
|
|
|
static inline Datum
|
|
|
|
PathPGetDatum(const PATH *X)
|
|
|
|
{
|
|
|
|
return PointerGetDatum(X);
|
|
|
|
}
|
2000-07-29 20:46:12 +02:00
|
|
|
#define PG_GETARG_PATH_P(n) DatumGetPathP(PG_GETARG_DATUM(n))
|
|
|
|
#define PG_GETARG_PATH_P_COPY(n) DatumGetPathPCopy(PG_GETARG_DATUM(n))
|
|
|
|
#define PG_RETURN_PATH_P(x) return PathPGetDatum(x)
|
2000-06-13 09:35:40 +02:00
|
|
|
|
2022-09-27 20:47:07 +02:00
|
|
|
static inline LINE *
|
|
|
|
DatumGetLineP(Datum X)
|
|
|
|
{
|
|
|
|
return (LINE *) DatumGetPointer(X);
|
|
|
|
}
|
|
|
|
static inline Datum
|
|
|
|
LinePGetDatum(const LINE *X)
|
|
|
|
{
|
|
|
|
return PointerGetDatum(X);
|
|
|
|
}
|
2000-06-13 09:35:40 +02:00
|
|
|
#define PG_GETARG_LINE_P(n) DatumGetLineP(PG_GETARG_DATUM(n))
|
|
|
|
#define PG_RETURN_LINE_P(x) return LinePGetDatum(x)
|
|
|
|
|
2022-09-27 20:47:07 +02:00
|
|
|
static inline BOX *
|
|
|
|
DatumGetBoxP(Datum X)
|
|
|
|
{
|
|
|
|
return (BOX *) DatumGetPointer(X);
|
|
|
|
}
|
|
|
|
static inline Datum
|
|
|
|
BoxPGetDatum(const BOX *X)
|
|
|
|
{
|
|
|
|
return PointerGetDatum(X);
|
|
|
|
}
|
2000-06-13 09:35:40 +02:00
|
|
|
#define PG_GETARG_BOX_P(n) DatumGetBoxP(PG_GETARG_DATUM(n))
|
|
|
|
#define PG_RETURN_BOX_P(x) return BoxPGetDatum(x)
|
|
|
|
|
2022-09-27 20:47:07 +02:00
|
|
|
static inline POLYGON *
|
|
|
|
DatumGetPolygonP(Datum X)
|
|
|
|
{
|
|
|
|
return (POLYGON *) PG_DETOAST_DATUM(X);
|
|
|
|
}
|
|
|
|
static inline POLYGON *
|
|
|
|
DatumGetPolygonPCopy(Datum X)
|
|
|
|
{
|
|
|
|
return (POLYGON *) PG_DETOAST_DATUM_COPY(X);
|
|
|
|
}
|
|
|
|
static inline Datum
|
|
|
|
PolygonPGetDatum(const POLYGON *X)
|
|
|
|
{
|
|
|
|
return PointerGetDatum(X);
|
|
|
|
}
|
2000-07-29 20:46:12 +02:00
|
|
|
#define PG_GETARG_POLYGON_P(n) DatumGetPolygonP(PG_GETARG_DATUM(n))
|
|
|
|
#define PG_GETARG_POLYGON_P_COPY(n) DatumGetPolygonPCopy(PG_GETARG_DATUM(n))
|
|
|
|
#define PG_RETURN_POLYGON_P(x) return PolygonPGetDatum(x)
|
2000-06-13 09:35:40 +02:00
|
|
|
|
2022-09-27 20:47:07 +02:00
|
|
|
static inline CIRCLE *
|
|
|
|
DatumGetCircleP(Datum X)
|
|
|
|
{
|
|
|
|
return (CIRCLE *) DatumGetPointer(X);
|
|
|
|
}
|
|
|
|
static inline Datum
|
|
|
|
CirclePGetDatum(const CIRCLE *X)
|
|
|
|
{
|
|
|
|
return PointerGetDatum(X);
|
|
|
|
}
|
2000-06-13 09:35:40 +02:00
|
|
|
#define PG_GETARG_CIRCLE_P(n) DatumGetCircleP(PG_GETARG_DATUM(n))
|
|
|
|
#define PG_RETURN_CIRCLE_P(x) return CirclePGetDatum(x)
|
|
|
|
|
|
|
|
|
1996-08-28 03:59:28 +02:00
|
|
|
/*
|
2016-12-28 18:00:00 +01:00
|
|
|
* in geo_ops.c
|
1996-08-28 03:59:28 +02:00
|
|
|
*/
|
1997-07-29 18:16:14 +02:00
|
|
|
|
2018-08-16 19:56:11 +02:00
|
|
|
extern float8 pg_hypot(float8 x, float8 y);
|
1997-07-29 18:16:14 +02:00
|
|
|
|
1996-08-28 03:59:28 +02:00
|
|
|
#endif /* GEO_DECLS_H */
|