Re: record identical operator

From: Hannu Krosing <hannu(at)krosing(dot)net>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Kevin Grittner <kgrittn(at)ymail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: record identical operator
Date: 2013-09-17 13:30:29
Message-ID: 52385975.4040501@krosing.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 09/17/2013 12:52 AM, Andres Freund wrote:
> On 2013-09-16 15:26:08 -0700, Kevin Grittner wrote:
>>> I can understand claiming that the risk is acceptable but arguing
>>> it's not there seems extremly strange to me.
>> It's not a risk. It's why the operator exists.
> Pft. It's fine if the materialized view code uses it. I don't see the
> danger there.
> It's about users discovering it. If they notice it, they will use it
> because "its a crapload faster" than normal row comparisons. And deals
> with NULLs in a "simpler" way.
This is why I suggested naming the operator ==== with four '='s
as this should make the user ponder why there are so many equal signs.
And there are other languages where more equal signs mean "stronger"
equality.

Basically it is "equality with possible false negatives".

If a user wants to use it for speeding up simple equality, it should be
used as
"WHERE t.* ==== sample AND t.* = sample"

>
>> Perhaps the name
>> of the operator (===) or the fact that I've been using the
>> shorthand description of "identical" instead of writing out "record
>> image equals" in these emails has confused you.
> If you really think that "confusing you" is the correct description for
> concerns about users not understanding limitations (which you didn't
> seem to know about),
IIRC he did start with a visible limitation of = being too weak equality
for some fields
> go ahead. Way to go to solicit feedback.
>
>> I can stop using
>> the shorter description and have absolutely no attachment to the
>> operator name, if that helps.
> You're unfortunately going to need operators if you want mergejoins to
> work, right? If not I'd have said name it matview_needs_update() or
> something like that... But yes, === certainly seems like a bad idea.
but having === as an operator form of IS NOT DISTINCT FROM
seems like a good idea to me.

We will get an operator which most people expect, with sufficiently
strange name to make people look up the docs and we will not be
violating SQL spec.

And it prepares their heads for stronger semantics of ==== :)
>
> Greetings,
>
> Andres Freund
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jaime Casanova 2013-09-17 13:37:06 Re: Minmax indexes
Previous Message Hannu Krosing 2013-09-17 13:14:52 Re: record identical operator