Re: record identical operator

On Thu, Sep 12, 2013 at 11:27 PM, Kevin Grittner <kgrittn(at)ymail(dot)com> wrote:

> Attached is a patch for a bit of infrastructure I believe to be
> necessary for correct behavior of REFRESH MATERIALIZED VIEW
> CONCURRENTLY as well as incremental maintenance of matviews.
> [...]
> The patch adds an "identical" operator (===) for the record type:
>

[...]

> The new operator is logically similar to IS NOT DISTINCT FROM for a
> record, although its implementation is very different. For one
> thing, it doesn't replace the operation with column level operators
> in the parser. For another thing, it doesn't look up operators for
> each type, so the "identical" operator does not need to be
> implemented for each type to use it as shown above. It compares
> values byte-for-byte, after detoasting. The test for identical
> records can avoid the detoasting altogether for any values with
> different lengths, and it stops when it finds the first column with
> a difference.
>
> I toyed with the idea of supporting hashing of records using this
> operator, but could not see how that would be a performance win.
>
> The identical (===) and not identical (!==) operator names were
> chosen because of a vague similarity to the "exactly equals"
> concepts in JavaScript and PHP, which use that name. The semantics
> aren't quite the same, but it seemed close enough not to be too
> surprising. The additional operator names seemed natural to me
> based on the first two, but I'm not really that attached to these
> names for the operators if someone has a better idea.
>
> Since the comparison of record values is not documented (only
> comparisons involving row value constructors), it doesn't seem like
> we should document this special case. It is intended primarily for
> support of matview refresh and maintenance, and it seems likely
> that record comparison was not documented on the basis that it is
> intended primarily for support of such things as indexing and merge
> joins -- so leaving the new operators undocumented seems consistent
> with existing policy. I'm open to arguments that the policy should
> change.
>
> -
>

Wouldn't it be slightly less surprising / magical to not declare new
operators
but just new primitive functions? In the least invasive version they could
even
be called matview_is_record_identical or similar.

cheers,

Bene