Re: record identical operator

Andres Freund <andres@2ndquadrant.com> 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.

To have clean semantics, I think the operator should mean that the
stored format of the row is the same.  Regarding the array null
bitmap example, I think it would be truly weird if the operator
said that the stored format was the same, but this happened:

test=# select pg_column_size(ARRAY[1,2,3]);
 pg_column_size
----------------
             36
(1 row)

test=# select pg_column_size((ARRAY[1,2,3,NULL])::int4[3]);
 pg_column_size
----------------
             44
(1 row)

They have the same stored format, but a different number of
bytes?!?

> And deals with NULLs in a "simpler" way.

That might be addressed by leaving room to implement IS NOT
DISTINCT FROM as an operator.  See below.

>> 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), go ahead. Way
> to go to solicit feedback.

I see how that could be taken in a pejorative way; that was not
intended.  I apologize.  I was rushing a bit on that email to make
an appointment shortly afterward.  The point was to suggest that
bad communication on my part about the intent and concept of the
operator may have contributed to you saying that there was a risk
of it working as intended.  There is perhaps a risk that someone
will think that it does something other than what is intended, but
when you say that there is a "risk" that it will behave exactly as
intended, it does suggest that we're talking past each other.

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

Yes, operators are needed for that.

> If not I'd have said name it matview_needs_update() or something
> like that... But yes, === certainly seems like a bad idea.

I've come to agree with that.  The appointment was to meet with a
local PostgreSQL user who I've talked to before.  He reminded me
that his pet peeve was that he couldn't use IS [ NOT ] DISTINCT
FROM with the ALL | ANY construct because the IS [ NOT ] DISTINCT
FROM predicate isn't an operator.


Hannu Krosing <hannu@2ndQuadrant.com> wrote:

> Maybe the binary equality operator should be named ====
> for "really deeply equal"
>
> to distinguish it from === which would be merely NOT DISTINCT FROM
>
> we could even go one step further and define ===== to mean "the same".
>
> ?
>
> This could fit better in conceptual sequence of operator 'strength'

I'm inclined to go with this.  It would leave the door open to
implementing IS NOT DISTINCT FROM on a type-by-type basis.  My one
concern is that it doesn't make room for a "has no user-visible
differences from" operator; but I'm not sure whether that is
something that there really is any use for.  But if we want to
reserve name space for it "just in case" someone has a use for it,
that would be between IS NOT DISTINCT FROM and "has the same
storage representation as", so that would leave:

  =      equals (but doesn't necessarily look the same as)
  ===    IS NOT DISTINCT FROM as an operator
  ====   reserved for "has no user-visible differences from"
  =====  stored image is the same

Of course, that begs the question of whether == is already "taken".
If not, we could knock one '=' off of everything above except for
"equals".  What existing uses are known for == ?

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company