Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> Could you try the follwoing patch ?
> Hiroshi, I don't see this in the main tree, nor do I see it having been
> requested for application. Should I apply it?
If this does fix things, I would venture that the blame really belongs
to whatever caller of the comparison function is failing to interpret
the return value correctly ...
BTW there is a somewhat-related issue that has been bothering me:
the system is pretty erratic about converting between Datum and bool.
Some places use "DatumGetInt32(datum) != 0" as their effective test
for whether a Datum value is "true", some places use
"DatumGetInt8(datum) != 0", some places just do "(bool) datum", and
there may be other variants.
I am thinking of introducing DatumGetBool and BoolGetDatum macros and
trying to make the code use those uniformly, but there's a lot of code
to clean up. I was intending to do it during the function manager
interface rewrite, since all these same places will need to be looked
at for that.
Perhaps we should also try to clean up btree's sort comparison functions
in the same way, with some macros that provide a well-defined conversion
between Datum and the "<", "=", ">" return conditions that are intended.
regards, tom lane
