BUG #4647: Geometric functions reorder their parameters randomly

Started by Juho Saarikkoabout 17 years ago2 messagesbugs
Jump to latest
#1Juho Saarikko
juho.saarikko@gmail.com

The following bug has been logged online:

Bug reference: 4647
Logged by: Juho Saarikko
Email address: juho.saarikko@gmail.com
PostgreSQL version: 8.3.6
Operating system: Linux
Description: Geometric functions reorder their parameters randomly
Details:

According to the online documentation, the ## operator is supposed to return
"Closest point to first operand on second operand". However, in reality it
seems to decide reorder its parameters as a function of them. That is,
sometimes it returns a point on the first operand, and sometimes a point on
the second operand, depending on what those operands are, but seemingly
consistently for a given set of operands.

This behaviour is also present in 8.3.5.

PostgreSQL output (from psql) demonstrating this behaviour:
**************************************

test=# select lseg '((1,1),(1,0))' ## box '((-2,-2),(-4,-4))';
?column?
----------
(1,0)
(1 row)

test=# select lseg '((0,1),(1,0))' ## box '((-2,-2),(-4,-4))';
?column?
----------
(-2,-2)
(1 row)

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Juho Saarikko (#1)
Re: BUG #4647: Geometric functions reorder their parameters randomly

"Juho Saarikko" <juho.saarikko@gmail.com> writes:

According to the online documentation, the ## operator is supposed to return
"Closest point to first operand on second operand". However, in reality it
seems to decide reorder its parameters as a function of them.

In the example you give, it looks like close_lseg (which close_sb
depends on) will sometimes return a point on its first argument
instead of its second one. If you think that the problem isn't
restricted to these two operators then you need to be more complete.

regards, tom lane