Gregory Stark <stark@enterprisedb.com> writes:
> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
>> The alternative seems to be to forbid uninitialized pad bytes within
>> Datums. That's not very pleasant to contemplate either, since it'll
>> forever be vulnerable to sins of omission.
> Just brainstorming here, I don't think this is a good solution but perhaps it
> could lead somewhere interesting...
> We could have actual equal operators include an assertion that the datums are
> also datumIsEqual? That isn't guaranteed to catch every case but it would be
> good for complex data types like arrays.
That still puts the responsibility on the individual datatype author to
get it right. The case I'm most worried about is user-written datatypes
that are never going to magically acquire such asserts.
There is another path we could try to take, which is to fix things so
that there aren't any cases where a false not-equal report will break
critical behavior. I seem to recall that the original justification for
implementing equal() this way was exactly the argument that it didn't
matter if you sometimes got a false not-equal report, so long as
copyObject() was guaranteed to generate equal() trees (which it is).
This also seems prone to somebody breaking the assumption in future,
though, even assuming that we can make it work like that today.
(I'm not too sure how to deal with the ORDER-BY/DISTINCT semantics
without it.) I guess we could have a test mode in which datumIsEqual
always returned false...
regards, tom lane