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 tWHERE 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
