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
|
|
|
*
|
|
|
|
*
|
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-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
|
|
|
*
|
|
|
|
* NOTE
|
1997-09-07 07:04:48 +02:00
|
|
|
* These routines do *not* use the float types from adt/.
|
1996-08-28 03:59:28 +02:00
|
|
|
*
|
1997-09-07 07:04:48 +02:00
|
|
|
* XXX These routines were not written by a numerical analyst.
|
2000-02-17 04:40:02 +01:00
|
|
|
*
|
1997-09-07 07:04:48 +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
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
1997-09-07 07:04:48 +02:00
|
|
|
#ifndef GEO_DECLS_H
|
|
|
|
#define GEO_DECLS_H
|
1996-08-28 03:59:28 +02:00
|
|
|
|
2006-07-13 18:49:20 +02: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.
|
1996-08-28 03:59:28 +02:00
|
|
|
*-------------------------------------------------------------------*/
|
|
|
|
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
#define EPSILON 1.0E-06
|
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
|
|
|
#ifdef EPSILON
|
1997-09-07 07:04:48 +02:00
|
|
|
#define FPzero(A) (fabs(A) <= EPSILON)
|
|
|
|
#define FPeq(A,B) (fabs((A) - (B)) <= EPSILON)
|
2000-07-30 22:44:02 +02:00
|
|
|
#define FPne(A,B) (fabs((A) - (B)) > EPSILON)
|
1997-09-07 07:04:48 +02:00
|
|
|
#define FPlt(A,B) ((B) - (A) > EPSILON)
|
|
|
|
#define FPle(A,B) ((A) - (B) <= EPSILON)
|
|
|
|
#define FPgt(A,B) ((A) - (B) > EPSILON)
|
|
|
|
#define FPge(A,B) ((B) - (A) <= EPSILON)
|
Major patch from Thomas Lockhart <Thomas.G.Lockhart@jpl.nasa.gov>
OK, here are a passel of patches for the geometric data types.
These add a "circle" data type, new operators and functions
for the existing data types, and change the default formats
for some of the existing types to make them consistant with
each other. Current formatting conventions (e.g. compatible
with v6.0 to allow dump/reload) are supported, but the new
conventions should be an improvement and we can eventually
drop the old conventions entirely.
For example, there are two kinds of paths (connected line segments),
open and closed, and the old format was
'(1,2,1,2,3,4)' for a closed path with two points (1,2) and (3,4)
'(0,2,1,2,3,4)' for an open path with two points (1,2) and (3,4)
Pretty arcane, huh? The new format for paths is
'((1,2),(3,4))' for a closed path with two points (1,2) and (3,4)
'[(1,2),(3,4)]' for an open path with two points (1,2) and (3,4)
For polygons, the old convention is
'(0,4,2,0,4,3)' for a triangle with points at (0,0),(4,4), and (2,3)
and the new convention is
'((0,0),(4,4),(2,3))' for a triangle with points at (0,0),(4,4), and (2,3)
Other data types which are also represented as lists of points
(e.g. boxes, line segments, and polygons) have similar representations
(they surround each point with parens).
For v6.1, any format which can be interpreted as the old style format
is decoded as such; we can remove that backwards compatibility but ugly
convention for v7.0. This will allow dump/reloads from v6.0.
These include some updates to the regression test files to change the test
for creating a data 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
|
|
|
*-------------------------------------------------------------------*/
|
1997-09-07 07:04:48 +02:00
|
|
|
typedef struct
|
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
double x,
|
|
|
|
y;
|
1997-09-08 23:56:23 +02:00
|
|
|
} Point;
|
1996-08-28 03:59:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
/*---------------------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* LSEG - A straight line, specified by endpoints.
|
1996-08-28 03:59:28 +02:00
|
|
|
*-------------------------------------------------------------------*/
|
1997-09-07 07:04:48 +02:00
|
|
|
typedef struct
|
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
Point p[2];
|
1997-09-08 23:56:23 +02:00
|
|
|
} LSEG;
|
1996-08-28 03:59:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
/*---------------------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* PATH - Specified by vertex points.
|
1996-08-28 03:59:28 +02:00
|
|
|
*-------------------------------------------------------------------*/
|
1997-09-07 07:04:48 +02:00
|
|
|
typedef struct
|
|
|
|
{
|
2007-02-28 00:48:10 +01:00
|
|
|
int32 vl_len_; /* varlena header (do not touch directly!) */
|
1997-09-08 04:41:22 +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];
|
1997-09-08 23:56:23 +02:00
|
|
|
} PATH;
|
1996-08-28 03:59:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
/*---------------------------------------------------------------------
|
1997-09-07 07:04:48 +02:00
|
|
|
* LINE - Specified by its general equation (Ax+By+C=0).
|
1996-08-28 03:59:28 +02:00
|
|
|
*-------------------------------------------------------------------*/
|
1997-09-07 07:04:48 +02:00
|
|
|
typedef struct
|
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
double A,
|
|
|
|
B,
|
|
|
|
C;
|
1997-09-08 23:56:23 +02:00
|
|
|
} LINE;
|
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
|
|
|
* BOX - Specified by two corner points, which are
|
1997-09-07 07:04:48 +02:00
|
|
|
* sorted to save calculation time later.
|
1996-08-28 03:59:28 +02:00
|
|
|
*-------------------------------------------------------------------*/
|
1997-09-07 07:04:48 +02:00
|
|
|
typedef struct
|
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
Point high,
|
|
|
|
low; /* corner POINTs */
|
1997-09-08 22:59:27 +02:00
|
|
|
} BOX;
|
1996-08-28 03:59:28 +02:00
|
|
|
|
|
|
|
/*---------------------------------------------------------------------
|
1997-09-07 07:04:48 +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
|
|
|
*-------------------------------------------------------------------*/
|
1997-09-07 07:04:48 +02:00
|
|
|
typedef struct
|
|
|
|
{
|
2007-02-28 00:48:10 +01:00
|
|
|
int32 vl_len_; /* varlena header (do not touch directly!) */
|
1997-09-08 04:41:22 +02:00
|
|
|
int32 npts;
|
|
|
|
BOX boundbox;
|
2015-02-20 06:11:42 +01:00
|
|
|
Point p[FLEXIBLE_ARRAY_MEMBER];
|
1997-09-08 23:56:23 +02:00
|
|
|
} POLYGON;
|
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
|
|
|
/*---------------------------------------------------------------------
|
|
|
|
* CIRCLE - Specified by a center point and radius.
|
|
|
|
*-------------------------------------------------------------------*/
|
1997-09-07 07:04:48 +02:00
|
|
|
typedef struct
|
|
|
|
{
|
1997-09-08 04:41:22 +02:00
|
|
|
Point center;
|
|
|
|
double radius;
|
1997-09-08 23:56:23 +02:00
|
|
|
} CIRCLE;
|
1996-08-28 03:59:28 +02:00
|
|
|
|
2000-06-13 09:35:40 +02:00
|
|
|
/*
|
|
|
|
* fmgr interface macros
|
|
|
|
*
|
|
|
|
* Path and Polygon are toastable varlena types, the others are just
|
|
|
|
* fixed-size pass-by-reference types.
|
|
|
|
*/
|
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
#define DatumGetPointP(X) ((Point *) DatumGetPointer(X))
|
|
|
|
#define PointPGetDatum(X) 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)
|
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
#define DatumGetLsegP(X) ((LSEG *) DatumGetPointer(X))
|
|
|
|
#define LsegPGetDatum(X) 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)
|
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
#define DatumGetPathP(X) ((PATH *) PG_DETOAST_DATUM(X))
|
|
|
|
#define DatumGetPathPCopy(X) ((PATH *) PG_DETOAST_DATUM_COPY(X))
|
|
|
|
#define PathPGetDatum(X) PointerGetDatum(X)
|
|
|
|
#define PG_GETARG_PATH_P(n) DatumGetPathP(PG_GETARG_DATUM(n))
|
2000-07-29 20:46:12 +02:00
|
|
|
#define PG_GETARG_PATH_P_COPY(n) DatumGetPathPCopy(PG_GETARG_DATUM(n))
|
2001-03-22 05:01:46 +01:00
|
|
|
#define PG_RETURN_PATH_P(x) return PathPGetDatum(x)
|
2000-06-13 09:35:40 +02:00
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
#define DatumGetLineP(X) ((LINE *) DatumGetPointer(X))
|
|
|
|
#define LinePGetDatum(X) 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)
|
|
|
|
|
|
|
|
#define DatumGetBoxP(X) ((BOX *) DatumGetPointer(X))
|
|
|
|
#define BoxPGetDatum(X) PointerGetDatum(X)
|
|
|
|
#define PG_GETARG_BOX_P(n) DatumGetBoxP(PG_GETARG_DATUM(n))
|
|
|
|
#define PG_RETURN_BOX_P(x) return BoxPGetDatum(x)
|
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
#define DatumGetPolygonP(X) ((POLYGON *) PG_DETOAST_DATUM(X))
|
|
|
|
#define DatumGetPolygonPCopy(X) ((POLYGON *) PG_DETOAST_DATUM_COPY(X))
|
|
|
|
#define PolygonPGetDatum(X) PointerGetDatum(X)
|
|
|
|
#define PG_GETARG_POLYGON_P(n) DatumGetPolygonP(PG_GETARG_DATUM(n))
|
2000-07-29 20:46:12 +02:00
|
|
|
#define PG_GETARG_POLYGON_P_COPY(n) DatumGetPolygonPCopy(PG_GETARG_DATUM(n))
|
2001-03-22 05:01:46 +01:00
|
|
|
#define PG_RETURN_POLYGON_P(x) return PolygonPGetDatum(x)
|
2000-06-13 09:35:40 +02:00
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
#define DatumGetCircleP(X) ((CIRCLE *) DatumGetPointer(X))
|
|
|
|
#define CirclePGetDatum(X) 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)
|
|
|
|
|
|
|
|
|
1997-09-07 07:04:48 +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
|
|
|
|
2010-08-03 23:21:03 +02:00
|
|
|
extern double pg_hypot(double x, double y);
|
1997-07-29 18:16:14 +02:00
|
|
|
|
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
|
|
|
#endif /* GEO_DECLS_H */
|