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@t-online.de 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