Hi Tom, declaring another operator class helped. At first, however, results were sorted deifferent than expected. A little gdb session revealed that if fact only the FUNCTION 1 entry in the operator class is used Regards Wolfgang Hamann >> >> hamann.w@xxxxxxxxxxx writes: >> > Now, in versions 8 and later the "using <&-" is rejected, >> > the ordering op "needs to be < or > member of a btree operator class". >> > What is needed to create the old behaviour again >> > - create a complete operator class, including new names for the unchanged equals/not equals function? >> >> Yes. It sounds like you have pretty much all the spare parts you need, >> you just have to collect them together into an opclass for each >> ordering you want. >> >> > Is this relevant to performance? >> >> Somewhat, in that it helps the planner optimize ordering considerations. >> But IIRC the main argument for tightening it up was to catch mistakes >> wherein somebody says "ORDER BY x USING &&", or some other operator that >> doesn't produce a consistent sort order. >> >> regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
