> geometry regression test:
>
> QUERY: SELECT '' AS thirty, p.f1, l.s, p.f1 ## l.s AS closest
> FROM LSEG_TBL l, POINT_TBL p;
> thirty|f1 |s |closest
>
> ------+----------+-----------------------------+--------------------------------
> ----
> |(0,0) |[(1,2),(3,4)] |(1,2)
>
> |(-10,0) |[(1,2),(3,4)] |(1,2)
>
> |(-3,4) |[(1,2),(3,4)] |(1,2)
>
> |(5.1,34.5)|[(1,2),(3,4)] |(3,4)
>
> |(-5,-12) |[(1,2),(3,4)] |(1,2)
>
> |(10,10) |[(1,2),(3,4)] |(3,4)
>
> |(0,0) |[(0,0),(6,6)] |(-0,0)
>
> This last line, in the current results, provides a value of (0,0) for
> closest, but I can't find what ## means in order to determine if this is
> as expected...
It is the "closest point on" operator. I've been working on the geometric operators
today, and will submit some fix-up patches soon (hopefully by Tuesday). Will
augment the regression test for geometry also. (I've been adding entries to the
"DESCR" macros in pg_proc.h and pg_operator.h, so there will be a description
available.)
I assume that the "-0" is just a rounding artifact on your machine.
There were two regression tests whose CVS expected results should probably be
backed out. I was getting different results and had convinced myself that they were
reasonable, but a week or two later someone fixed the backend problem and the
behavior reverted to the original. Look for the last two cvs updates by thomas in
the expected subdirectory.
- Tom
