From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Strange sort operators vs the regression tests |
Date: | 2007-01-08 23:56:27 |
Message-ID: | 1107.1168300587@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
There was some discussion recently of simplifying the sorting code (and
hopefully making it a tad faster) by eliminating support for using
randomly-chosen operators in ORDER BY ... USING, and requiring USING to
specify an operator that is the < or > member of some btree opclass.
This strikes me as a good idea in any case since a USING operator that
doesn't act like < or > is probably not going to yield a consistent sort
order.
However, when I went to do this as part of the NULLS FIRST/LAST + DESC
index order patch I'm working on, I found out that removing this feature
makes the regression tests fail: specifically, there are tests that
assume they can ORDER BY with these operators:
<(circle,circle) circle_lt
<<(polygon,polygon) poly_left
<(box,box) box_lt
<<(point,point) point_left
I thought for a bit about adding btree opclasses covering these cases,
but it seems a bit silly ... and actually I think the sorts on poly_left
and point_left are not even self-consistent because I don't think these
operators satisfy the trichotomy law.
What I'm inclined to do is change the tests a bit, eg do "ORDER BY
area(circle)", which is what's really happening with circle_lt anyway.
Anybody unhappy with that plan?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2007-01-09 00:07:29 | Re: [HACKERS] SGML index build fix |
Previous Message | Andreas Pflug | 2007-01-08 23:09:27 | Re: -f <output file> option for pg_dumpall |