On 10/04/2013 12:22 AM, Stephen Frost wrote: > That said, I agree that PG, in general, is more 'open' to exposing > implementation details than is perhaps ideal, Every *real* system is more open to exposing implementation details than is *ideal*.
One very popular "implementation detail" which surprises users over and over is performance under different use cases. There is no way you can hide this. That said, I see nothing bad in having an operator for "binary equal" or alternately called "guaranteed equal". Its negator is not "guaranteed unequal" but "not guaranteed to be equal" The main exposed implementation detail of this operator is that it is very fast and can be recommended to be used at user level for speeding up equal query like this SELECT * FROM t WHERE <guaranteed equal> or <equal> where the plain <equal> will only be called when fast <guaranteed equal> fails. a bit similar to how you can cut down on index size on long text fields by indexing their hashes and then querying SELECT * FROM t WHERE hashtext(verylongtext) = hashtext(sample) AND verylongtext = sample It is absolutely possible that the fact that hash clashes exist also confuses some users the same way the possibility of having binary inequality and be still NOT DISTINCT FROM, but I argue that having a fast "guaranteed equal" operation available to users is useful. some users may also initially get confused by SELECT 3/2; returning 1 and not "the right answer" of 1.5. They may even bitch and moan that PostgreSQL is completely broken. But then they look it up or ask on the net and are confused no more. Greetings Hannu -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers