Thread: BUG #4647: Geometric functions reorder their parameters randomly

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)

"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