Re: [HACKERS] [PATCH] Revive line type
On Wed, Oct 9, 2013 at 10:44 AM, Peter Eisentraut pete...@gmx.net wrote: On Thu, 2013-10-03 at 17:50 +0530, Jeevan Chalke wrote: Will you please attach new patch with above block removed ? Then I will quickly check that new patch and mark as Ready For Committer. Here you go. Thanks Peter. Patch looks good to me and ready to go in now. Marking as Ready For Committer. -- Jeevan B Chalke Principal Software Engineer, Product Development EnterpriseDB Corporation
Re: [HACKERS] [PATCH] Revive line type
On Thu, 2013-10-03 at 17:50 +0530, Jeevan Chalke wrote:
Will you please attach new patch with above block removed ? Then I
will quickly check that new patch and mark as Ready For Committer.
Here you go.
From ba421c778cc3f7c32886ac038389cfbad3c0df67 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut pete...@gmx.net
Date: Wed, 9 Oct 2013 01:09:18 -0400
Subject: [PATCH v2] Revive line type
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Change the input/output format to {A,B,C}, to match the internal
representation.
Complete the implementations of line_in, line_out, line_recv, line_send.
Remove comments and error messages about the line type not being
implemented. Add regression tests for existing line operators and
functions.
Reviewed-by: rui hua 365507506...@gmail.com
Reviewed-by: Álvaro Herrera alvhe...@2ndquadrant.com
Reviewed-by: Jeevan Chalke jeevan.cha...@enterprisedb.com
---
doc/src/sgml/datatype.sgml | 42 -
doc/src/sgml/func.sgml | 6 +
src/backend/utils/adt/geo_ops.c| 224 ++--
src/include/catalog/pg_type.h | 3 +-
src/include/utils/geo_decls.h | 7 -
src/test/regress/expected/geometry.out | 3 -
src/test/regress/expected/line.out | 271 +
src/test/regress/expected/sanity_check.out | 3 +-
src/test/regress/output/misc.source| 3 +-
src/test/regress/parallel_schedule | 2 +-
src/test/regress/serial_schedule | 1 +
src/test/regress/sql/geometry.sql | 4 -
src/test/regress/sql/line.sql | 87 +
13 files changed, 503 insertions(+), 153 deletions(-)
create mode 100644 src/test/regress/expected/line.out
create mode 100644 src/test/regress/sql/line.sql
diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml
index 87668ea..07f0385 100644
--- a/doc/src/sgml/datatype.sgml
+++ b/doc/src/sgml/datatype.sgml
@@ -3051,9 +3051,7 @@ titleGeometric Types/title
para
Geometric data types represent two-dimensional spatial
objects. xref linkend=datatype-geo-table shows the geometric
-types available in productnamePostgreSQL/productname. The
-most fundamental type, the point, forms the basis for all of the
-other types.
+types available in productnamePostgreSQL/productname.
/para
table id=datatype-geo-table
@@ -3063,8 +3061,8 @@ titleGeometric Types/title
row
entryName/entry
entryStorage Size/entry
-entryRepresentation/entry
entryDescription/entry
+entryRepresentation/entry
/row
/thead
tbody
@@ -3077,8 +3075,8 @@ titleGeometric Types/title
row
entrytypeline/type/entry
entry32 bytes/entry
-entryInfinite line (not fully implemented)/entry
-entry((x1,y1),(x2,y2))/entry
+entryInfinite line/entry
+entry{A,B,C}/entry
/row
row
entrytypelseg/type/entry
@@ -3153,6 +3151,38 @@ titlePoints/title
/sect2
sect2
+titleLines/title
+
+indexterm
+ primaryline/primary
+/indexterm
+
+para
+ Lines (typeline/type) are represented by the linear equation Ax + By
+ + C = 0, where A and B are not both zero. Values of
+ type typeline/type is input and output in the following form:
+synopsis
+{ replaceableA/replaceable, replaceableB/replaceable, replaceableC/replaceable }
+/synopsis
+
+ Alternatively, any of the following forms can be used for input:
+
+synopsis
+[ ( replaceablex1/replaceable , replaceabley1/replaceable ) , ( replaceablex2/replaceable , replaceabley2/replaceable ) ]
+( ( replaceablex1/replaceable , replaceabley1/replaceable ) , ( replaceablex2/replaceable , replaceabley2/replaceable ) )
+ ( replaceablex1/replaceable , replaceabley1/replaceable ) , ( replaceablex2/replaceable , replaceabley2/replaceable )
+replaceablex1/replaceable , replaceabley1/replaceable , replaceablex2/replaceable , replaceabley2/replaceable
+/synopsis
+
+ where
+ literal(replaceablex1/replaceable,replaceabley1/replaceable)/literal
+ and
+ literal(replaceablex2/replaceable,replaceabley2/replaceable)/literal
+ are two (different) points on the line.
+/para
+ /sect2
+
+ sect2
titleLine Segments/title
indexterm
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 7dd1ef2..b162618 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -8123,6 +8123,12 @@ titleGeometric Type Conversion Functions/title
entryliteralcircle(polygon '((0,0),(1,1),(2,0))')/literal/entry
/row
row
+entryliteralfunctionline(typepoint/type, typepoint/type)/function/literal/entry
+entrytypeline/type/entry
+entrypoints to line/entry
+entryliteralline(point '(-1,0)', point '(1,0)')/literal/entry
+ /row
+ row
entry
Re: [HACKERS] [PATCH] Revive line type
On Wed, Oct 2, 2013 at 6:12 AM, Peter Eisentraut pete...@gmx.net wrote:
On Wed, 2013-09-25 at 14:26 +0530, Jeevan Chalke wrote:
So no issues from my side.
However, do we still need this in close_pl() ?
#ifdef NOT_USED
if (FPeq(line-A, -1.0) FPzero(line-B))
{/* vertical */
}
#endif
No, that can be removed.
Will you please attach new patch with above block removed ? Then I will
quickly check that new patch and mark as Ready For Committer.
Also close_sl, close_lb and dist_lb are NOT yet implemented. It will
be good if we have those. But I don't think we should wait for those
functions to be implemented.
Right, those are separate projects.
Agree.
Thanks
--
Jeevan B Chalke
Re: [HACKERS] [PATCH] Revive line type
On Wed, 2013-09-25 at 14:26 +0530, Jeevan Chalke wrote:
So no issues from my side.
However, do we still need this in close_pl() ?
#ifdef NOT_USED
if (FPeq(line-A, -1.0) FPzero(line-B))
{/* vertical */
}
#endif
No, that can be removed.
Also close_sl, close_lb and dist_lb are NOT yet implemented. It will
be good if we have those. But I don't think we should wait for those
functions to be implemented.
Right, those are separate projects.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] Revive line type
Hi,
I had a look over this patch and here are my review points:
1. Patch applies cleanly.
2. make, make install and make check is good.
3. I did lot of random testing and didn't find any issue.
4. Test coverage is very well. It has all scenarios and all operators are
tested with line. That's really great.
So no issues from my side.
However, do we still need this in close_pl() ?
#ifdef NOT_USED
if (FPeq(line-A, -1.0) FPzero(line-B))
{/* vertical */
}
#endif
Also close_sl, close_lb and dist_lb are NOT yet implemented. It will be good
if we have those. But I don't think we should wait for those functions to be
implemented. We can go ahead with this. Please confirm above concern so that
I will mark it as Ready for Committer.
Thanks
On Tue, Sep 17, 2013 at 7:34 AM, Alvaro Herrera alvhe...@2ndquadrant.comwrote:
David Fetter escribió:
Should the things you tried and others be in the regression tests? If
so, should we start with whatever had been in the regression tests
when the line type was dropped?
Actually, the patch does include a regression test for the revived type
(and it passes). I don't think more than that is needed.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
Jeevan B Chalke
Principal Software Engineer, Product Development
EnterpriseDB Corporation
Re: [HACKERS] [PATCH] Revive line type
Peter Eisentraut escribió:
Here is a new patch for the line type, with a new input/output format
{A,B,C}, as discussed in this thread.
I gave this a quick look. The new input/output format appears to work
well. The input format using two points still works, which is nice.
Regression tests pass. I tried binary input and output using COPY and
it seems to round-trip without problem.
With the two-point input, horizontal and vertical lines can accept NaNs
without producing a NaN in the output if not necessary.
I tried interpt and intersect functions and they seem to work.
Haven't gotten around to trying other functions or operators.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] Revive line type
On Mon, Sep 16, 2013 at 07:04:32PM -0300, Alvaro Herrera wrote:
Peter Eisentraut escribió:
Here is a new patch for the line type, with a new input/output format
{A,B,C}, as discussed in this thread.
I gave this a quick look. The new input/output format appears to work
well. The input format using two points still works, which is nice.
Regression tests pass. I tried binary input and output using COPY and
it seems to round-trip without problem.
With the two-point input, horizontal and vertical lines can accept NaNs
without producing a NaN in the output if not necessary.
I tried interpt and intersect functions and they seem to work.
Haven't gotten around to trying other functions or operators.
Should the things you tried and others be in the regression tests? If
so, should we start with whatever had been in the regression tests
when the line type was dropped?
Cheers,
David.
--
David Fetter da...@fetter.org http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fet...@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] Revive line type
David Fetter escribió: Should the things you tried and others be in the regression tests? If so, should we start with whatever had been in the regression tests when the line type was dropped? Actually, the patch does include a regression test for the revived type (and it passes). I don't think more than that is needed. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] Revive line type
Here is a new patch for the line type, with a new input/output format
{A,B,C}, as discussed in this thread.
From 837fcf5d9b1ee8e589ef4b19f7d6e575229ca758 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut pete...@gmx.net
Date: Sun, 15 Sep 2013 00:02:06 -0400
Subject: [PATCH] Revive line type
Change the input/output format to {A,B,C}, to match the internal
representation.
Complete the implementations of line_in, line_out, line_recv,
line_send. Remove comments and error messages about the line type not
being implemented. Add regression tests for existing line operators
and functions.
Reviewed-by: rui hua 365507506...@gmail.com
---
doc/src/sgml/datatype.sgml | 42 -
doc/src/sgml/func.sgml | 6 +
src/backend/utils/adt/geo_ops.c| 219 ++-
src/include/catalog/pg_type.h | 3 +-
src/include/utils/geo_decls.h | 7 -
src/test/regress/expected/geometry.out | 3 -
src/test/regress/expected/line.out | 271 +
src/test/regress/expected/sanity_check.out | 3 +-
src/test/regress/output/misc.source| 3 +-
src/test/regress/parallel_schedule | 2 +-
src/test/regress/serial_schedule | 1 +
src/test/regress/sql/geometry.sql | 4 -
src/test/regress/sql/line.sql | 87 +
13 files changed, 503 insertions(+), 148 deletions(-)
create mode 100644 src/test/regress/expected/line.out
create mode 100644 src/test/regress/sql/line.sql
diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml
index 87668ea..07f0385 100644
--- a/doc/src/sgml/datatype.sgml
+++ b/doc/src/sgml/datatype.sgml
@@ -3051,9 +3051,7 @@ titleGeometric Types/title
para
Geometric data types represent two-dimensional spatial
objects. xref linkend=datatype-geo-table shows the geometric
-types available in productnamePostgreSQL/productname. The
-most fundamental type, the point, forms the basis for all of the
-other types.
+types available in productnamePostgreSQL/productname.
/para
table id=datatype-geo-table
@@ -3063,8 +3061,8 @@ titleGeometric Types/title
row
entryName/entry
entryStorage Size/entry
-entryRepresentation/entry
entryDescription/entry
+entryRepresentation/entry
/row
/thead
tbody
@@ -3077,8 +3075,8 @@ titleGeometric Types/title
row
entrytypeline/type/entry
entry32 bytes/entry
-entryInfinite line (not fully implemented)/entry
-entry((x1,y1),(x2,y2))/entry
+entryInfinite line/entry
+entry{A,B,C}/entry
/row
row
entrytypelseg/type/entry
@@ -3153,6 +3151,38 @@ titlePoints/title
/sect2
sect2
+titleLines/title
+
+indexterm
+ primaryline/primary
+/indexterm
+
+para
+ Lines (typeline/type) are represented by the linear equation Ax + By
+ + C = 0, where A and B are not both zero. Values of
+ type typeline/type is input and output in the following form:
+synopsis
+{ replaceableA/replaceable, replaceableB/replaceable, replaceableC/replaceable }
+/synopsis
+
+ Alternatively, any of the following forms can be used for input:
+
+synopsis
+[ ( replaceablex1/replaceable , replaceabley1/replaceable ) , ( replaceablex2/replaceable , replaceabley2/replaceable ) ]
+( ( replaceablex1/replaceable , replaceabley1/replaceable ) , ( replaceablex2/replaceable , replaceabley2/replaceable ) )
+ ( replaceablex1/replaceable , replaceabley1/replaceable ) , ( replaceablex2/replaceable , replaceabley2/replaceable )
+replaceablex1/replaceable , replaceabley1/replaceable , replaceablex2/replaceable , replaceabley2/replaceable
+/synopsis
+
+ where
+ literal(replaceablex1/replaceable,replaceabley1/replaceable)/literal
+ and
+ literal(replaceablex2/replaceable,replaceabley2/replaceable)/literal
+ are two (different) points on the line.
+/para
+ /sect2
+
+ sect2
titleLine Segments/title
indexterm
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index ee1c957..8f60c56 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -8123,6 +8123,12 @@ titleGeometric Type Conversion Functions/title
entryliteralcircle(polygon '((0,0),(1,1),(2,0))')/literal/entry
/row
row
+entryliteralfunctionline(typepoint/type, typepoint/type)/function/literal/entry
+entrytypeline/type/entry
+entrypoints to line/entry
+entryliteralline(point '(-1,0)', point '(1,0)')/literal/entry
+ /row
+ row
entry
indexterm
primarylseg/primary
diff --git a/src/backend/utils/adt/geo_ops.c b/src/backend/utils/adt/geo_ops.c
index 5d0b596..6bfe6d7 100644
--- a/src/backend/utils/adt/geo_ops.c
+++ b/src/backend/utils/adt/geo_ops.c
@@ -926,42 +926,82 @@ box_diagonal(PG_FUNCTION_ARGS)
Re: [HACKERS] [PATCH] Revive line type
On 6/26/13 9:34 PM, Peter Eisentraut wrote: Still wondering whether to use a A,B,C-based output format per Tom's comment. Wouldn't it also be helpful to remove The points used in the output are not necessarily the points used on input by making that not true? There are three obvious ways you might output a line: -Math class expectations of slope-intercept form: y = mx + b. Intercept forms don't handle both horizontal and vertical lines though, so that's easily out. -Pair of points. A casual observer might get lucky and observe putting a pair of points in and getting the same pair back again, then incorrectly assume that's normally the case. Seems better to never make that possible in the infinite line case. I'm reminded of how row output usually is in order gives a bad impression about ordering guarantees in SQL. -Ax+By+C=0 Outputting that third one, when it's also the internal form, handles any time of line; will show any assumptions about individual points being preserved are wrong; and avoids rounding errors too. The only downside seems to be that bounded lines are easier to show with a pair of points. I think that suggests an alternate, secondary output format would be useful though, rather than that a different default one is a good idea. -- Greg Smith 2ndQuadrant USg...@2ndquadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] Revive line type
On Sun, 2013-06-23 at 12:24 +0800, rui hua wrote:
Regression tests are all succeed, but several problems have be found while
ding some simple test. The updated document said that the points used in
the output are not necessarily the points used on input. I understand that
as long as they are marked on the same line. But when the input data
represents a horizontal or vertical line, the output is not exactly the
same line. It is another line parallel to it.
postgres=# select line('1,3,2,3');
line
-
[(0,-3),(1,-3)]
(1 row)
This was just using the wrong sign. Fixed.
In addition, when a straight line coincides with coordinate axis, output
appears -0, I do not know whether it is appropriate.
This is a matter of the floating-point operations. I don't think it's
on scope to worry about that. With the above fix, the cases you pointed
out go away anyway.
Negative value appeared when use - to calculate the distance between two
parallel lines.
Fixed with fabs().
New patch included. Still wondering whether to use a A,B,C-based output
format per Tom's comment.
From d765f8a515a6f3de0e68e68962e5109945260b8c Mon Sep 17 00:00:00 2001
From: Peter Eisentraut pete...@gmx.net
Date: Fri, 14 Jun 2013 20:23:15 -0400
Subject: [PATCH] Revive line type
Complete the implementations of line_in, line_out, line_recv,
line_send. Remove comments and error messages about the line type not
being implemented. Add regression tests for existing line operators
and functions.
Reviewed-by: rui hua 365507506...@gmail.com
---
doc/src/sgml/datatype.sgml | 34 +++-
doc/src/sgml/func.sgml |6 +
src/backend/utils/adt/geo_ops.c| 112 +---
src/include/catalog/pg_type.h |3 +-
src/include/utils/geo_decls.h |7 -
src/test/regress/expected/geometry.out |3 -
src/test/regress/expected/line.out | 267
src/test/regress/expected/sanity_check.out |3 +-
src/test/regress/output/misc.source|3 +-
src/test/regress/parallel_schedule |2 +-
src/test/regress/serial_schedule |1 +
src/test/regress/sql/geometry.sql |4 -
src/test/regress/sql/line.sql | 86 +
13 files changed, 443 insertions(+), 88 deletions(-)
create mode 100644 src/test/regress/expected/line.out
create mode 100644 src/test/regress/sql/line.sql
diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml
index f73e6b2..ecbbdd8 100644
--- a/doc/src/sgml/datatype.sgml
+++ b/doc/src/sgml/datatype.sgml
@@ -3066,7 +3066,7 @@ titleGeometric Types/title
row
entrytypeline/type/entry
entry32 bytes/entry
-entryInfinite line (not fully implemented)/entry
+entryInfinite line/entry
entry((x1,y1),(x2,y2))/entry
/row
row
@@ -3142,6 +3142,38 @@ titlePoints/title
/sect2
sect2
+titleLines/title
+
+indexterm
+ primaryline/primary
+/indexterm
+
+para
+ Lines (typeline/type) are specified by pairs of points.
+ Values of type typeline/type are specified using any of the following
+ syntaxes:
+
+synopsis
+[ ( replaceablex1/replaceable , replaceabley1/replaceable ) , ( replaceablex2/replaceable , replaceabley2/replaceable ) ]
+( ( replaceablex1/replaceable , replaceabley1/replaceable ) , ( replaceablex2/replaceable , replaceabley2/replaceable ) )
+ ( replaceablex1/replaceable , replaceabley1/replaceable ) , ( replaceablex2/replaceable , replaceabley2/replaceable )
+replaceablex1/replaceable , replaceabley1/replaceable , replaceablex2/replaceable , replaceabley2/replaceable
+/synopsis
+
+ where
+ literal(replaceablex1/replaceable,replaceabley1/replaceable)/literal
+ and
+ literal(replaceablex2/replaceable,replaceabley2/replaceable)/literal
+ are two (different) points on the line.
+/para
+
+para
+ Lines are output using the first syntax. The points used in the output
+ are not necessarily the points used on input.
+/para
+ /sect2
+
+ sect2
titleLine Segments/title
indexterm
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 8cf5385..fd0e4a3 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -8070,6 +8070,12 @@ titleGeometric Type Conversion Functions/title
entryliteralcircle(polygon '((0,0),(1,1),(2,0))')/literal/entry
/row
row
+entryliteralfunctionline(typepoint/type, typepoint/type)/function/literal/entry
+entrytypeline/type/entry
+entrypoints to line/entry
+entryliterallseg(point '(-1,0)', point '(1,0)')/literal/entry
+ /row
+ row
entry
indexterm
primarylseg/primary
diff --git a/src/backend/utils/adt/geo_ops.c b/src/backend/utils/adt/geo_ops.c
index ad18cf0..e668a21 100644
--- a/src/backend/utils/adt/geo_ops.c
+++
[HACKERS] [PATCH] Revive line type
Hi,
Test results are as follows:
Contents Purpose
This patch is for finishing the line type and related functions that not
done yet but listed in catalogs and documentation. There are no other new
features added in this patch.
The regression test cases which included in this patch, Documentation are
also updated.
Run
Regression tests are all succeed, but several problems have be found while
ding some simple test. The updated document said that the points used in
the output are not necessarily the points used on input. I understand that
as long as they are marked on the same line. But when the input data
represents a horizontal or vertical line, the output is not exactly the
same line. It is another line parallel to it.
For example:
postgres=# select line('1,3,2,3');
line
-
[(0,-3),(1,-3)]
(1 row)
postgres=# select line('1,3,1,6');
line
-
[(-1,0),(-1,1)]
(1 row)
In addition, when a straight line coincides with coordinate axis, output
appears -0, I do not know whether it is appropriate.
postgres=# select line('0,1,0,5');
line
-
[(-0,0),(-0,1)]
(1 row)
Negative value appeared when use - to calculate the distance between two
parallel lines.
postgres=# select line('1,1,2,1') - line('-1,-1,-2,-1') ;
?column?
--
-2
postgres=# select lseg('1,1,2,1') - line('-1,-1,-2,-1') ;
?column?
--
-2
(1 row)
The same situation occurs in distance calculation between point and a
straight line.
postgres=# select point('-1,1') - line('-3,0,-4,0') ;
?column?
--
-1
(1 row)
Should the distance be positive numbers?
Other functions seem work properly.
Performance
==
Because these functions is first implemented. So there is no relatively
comparison for the performance.
Conclusion
This patch lets line type worked. But there are some bugs. Additionally,
function close_sl not implemented.
With Regards,
Rui
Re: [HACKERS] [PATCH] Revive line type
Peter Eisentraut pete...@gmx.net writes: Complete the implementations of line_in, line_out, line_recv, line_send. Remove comments and error messages about the line type not being implemented. Add regression tests for existing line operators and functions. --- This just revives existing functionality, doesn't add anything new. One thing that the original code did not settle was how to convert a line in form Ax+By+C=0 to the two-points output form. Obviously, you can just pick to random points on the line, but I wonder whether there is a more standard solution. ISTM printing a line as two points is an unfortunate representational choice altogether. If the internal form is Ax+By+C=0, shouldn't the text form expose A,B,C directly? What you've got here necessarily suffers a lot of roundoff error during I/O conversions, and so it seems pretty likely to fail dump-and-reload tests. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] [PATCH] Revive line type
Complete the implementations of line_in, line_out, line_recv,
line_send. Remove comments and error messages about the line type not
being implemented. Add regression tests for existing line operators
and functions.
---
This just revives existing functionality, doesn't add anything new.
One thing that the original code did not settle was how to convert a
line in form Ax+By+C=0 to the two-points output form. Obviously, you
can just pick to random points on the line, but I wonder whether there
is a more standard solution.
doc/src/sgml/datatype.sgml | 34 +++-
doc/src/sgml/func.sgml |6 +
src/backend/utils/adt/geo_ops.c| 108 +
src/include/catalog/pg_type.h |3 +-
src/include/utils/geo_decls.h |7 -
src/test/regress/expected/geometry.out |3 -
src/test/regress/expected/line.out | 243
src/test/regress/expected/sanity_check.out |3 +-
src/test/regress/output/misc.source|3 +-
src/test/regress/parallel_schedule |2 +-
src/test/regress/serial_schedule |1 +
src/test/regress/sql/geometry.sql |4 -
src/test/regress/sql/line.sql | 77 +
13 files changed, 408 insertions(+), 86 deletions(-)
create mode 100644 src/test/regress/expected/line.out
create mode 100644 src/test/regress/sql/line.sql
diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml
index f73e6b2..ecbbdd8 100644
--- a/doc/src/sgml/datatype.sgml
+++ b/doc/src/sgml/datatype.sgml
@@ -3066,7 +3066,7 @@ titleGeometric Types/title
row
entrytypeline/type/entry
entry32 bytes/entry
-entryInfinite line (not fully implemented)/entry
+entryInfinite line/entry
entry((x1,y1),(x2,y2))/entry
/row
row
@@ -3142,6 +3142,38 @@ titlePoints/title
/sect2
sect2
+titleLines/title
+
+indexterm
+ primaryline/primary
+/indexterm
+
+para
+ Lines (typeline/type) are specified by pairs of points.
+ Values of type typeline/type are specified using any of the following
+ syntaxes:
+
+synopsis
+[ ( replaceablex1/replaceable , replaceabley1/replaceable ) , (
replaceablex2/replaceable , replaceabley2/replaceable ) ]
+( ( replaceablex1/replaceable , replaceabley1/replaceable ) , (
replaceablex2/replaceable , replaceabley2/replaceable ) )
+ ( replaceablex1/replaceable , replaceabley1/replaceable ) , (
replaceablex2/replaceable , replaceabley2/replaceable )
+replaceablex1/replaceable , replaceabley1/replaceable ,
replaceablex2/replaceable , replaceabley2/replaceable
+/synopsis
+
+ where
+
literal(replaceablex1/replaceable,replaceabley1/replaceable)/literal
+ and
+
literal(replaceablex2/replaceable,replaceabley2/replaceable)/literal
+ are two (different) points on the line.
+/para
+
+para
+ Lines are output using the first syntax. The points used in the output
+ are not necessarily the points used on input.
+/para
+ /sect2
+
+ sect2
titleLine Segments/title
indexterm
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 4c5af4b..835a189 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -8070,6 +8070,12 @@ titleGeometric Type Conversion Functions/title
entryliteralcircle(polygon '((0,0),(1,1),(2,0))')/literal/entry
/row
row
+entryliteralfunctionline(typepoint/type,
typepoint/type)/function/literal/entry
+entrytypeline/type/entry
+entrypoints to line/entry
+entryliterallseg(point '(-1,0)', point '(1,0)')/literal/entry
+ /row
+ row
entry
indexterm
primarylseg/primary
diff --git a/src/backend/utils/adt/geo_ops.c b/src/backend/utils/adt/geo_ops.c
index ad18cf0..61a1900 100644
--- a/src/backend/utils/adt/geo_ops.c
+++ b/src/backend/utils/adt/geo_ops.c
@@ -933,13 +933,8 @@
Datum
line_in(PG_FUNCTION_ARGS)
{
-#ifdef ENABLE_LINE_TYPE
char *str = PG_GETARG_CSTRING(0);
-#endif
LINE *line;
-
-#ifdef ENABLE_LINE_TYPE
- /* when fixed, modify not implemented, catalog/pg_type.h and SGML */
LSEGlseg;
int isopen;
char *s;
@@ -950,15 +945,13 @@
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
errmsg(invalid input syntax for type line:
\%s\, str)));
+ if (FPeq(lseg.p[0].x, lseg.p[1].x) FPeq(lseg.p[0].y, lseg.p[1].y))
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
+errmsg(invalid line specification: must be
two distinct points)));
+
line = (LINE *) palloc(sizeof(LINE));
line_construct_pts(line, lseg.p[0], lseg.p[1]);
-#else
- ereport(ERROR,
-
