Re: record identical operator

Andres Freund <andres@2ndquadrant.com> wrote:
> On 2013-09-16 14:39:30 -0700, Kevin Grittner wrote:
>> Andres Freund <andres@2ndquadrant.com> wrote:
>>> On 2013-09-16 16:58:21 -0400, Noah Misch wrote:
>>>> memcmp() has served well for HOT and for _equalConst(); why
>>>> would it suddenly fall short for MV maintenance?
>>>
>>> I don't have a problem using it internally, I have a problem
>>> exposing the capability to sql.
>>
>> ... like we do in *pattern ops and the
>
> That's still an absurd comparison. pattern ops have a defined
> behaviour, even for multibyte characters. After all, you can
> simply have a UTF-8 database with C collation. Remember, in a C
> collation pattern ops can use normal indexes.
> The only thing that happens is that multibyte chars are sorted
> differently. They aren't sorted basically randomly or anything.

Neither are records using the new operator -- there is a
deterministic sort order based on the bytes representing the
record's values.

>> suppress_redundant_updates_trigger() function?
>
> You get superflous trigger calls. So what.

My feeling exactly.

>> I'm really having trouble understanding what problem you have
>> with this.  Can you describe a scenario where someone shoots
>> themselves in the foot with it, because I'm not seeing any?
>
> It certainly will be surprising to just about anyone that
> something like:
>
> SELECT * FROM foo WHERE whatever_composite_or_row === '(...)';
>
> may not return rows where there's no SQL level discernible
> difference (even by looking at the text conversion) between
> whatever_composite_or_row and '(...)' because e.g. of the
> aforementioned array null bitmaps.

Since the operator is bound to a function named record_image_eq(),
it seems to me to be a feature that if the image isn't equal due to
a bitmap being present in one and not the other it says they
differ.  It's not a bug or a problem.  It gives you a way to *tell*
whether two rows actually have the same representation, which could
be valuable for debugging.  The closest you can easily come without
this is to see that pg_column_size() yields a different result for
them, where that is true (as in the array bitmap case).

> 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.  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.  I can stop using
the shorter description and have absolutely no attachment to the
operator name, if that helps.

The point of the operator is to determine whether two records,
which may compare as "equal" (but which don't necessarily appear
the same to a user), have the same byte image for each
corresponding value.  The point of the opfamily is to be able to do
a MergeJoin on this basis.

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