On Thu, Sep 12, 2013 at 11:27 PM, Kevin Grittner <kgri...@ymail.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
