On Sun, Sep 15, 2013 at 6:49 PM, Noah Misch <n...@leadboat.com> wrote: > On Sat, Sep 14, 2013 at 08:58:32PM +0200, Andres Freund wrote: >> On 2013-09-14 11:25:52 -0700, Kevin Grittner wrote: >> > Andres Freund <and...@2ndquadrant.com> wrote: >> > > But both arrays don't have the same binary representation since >> > > the former has a null bitmap, the latter not. So, if you had a >> > > composite type like (int4[]) and would compare that without >> > > invoking operators you'd return something false in some cases >> > > because of the null bitmaps. >> > >> > Not for the = operator. The new "identical" operator would find >> > them to not be identical, though. >> >> Yep. And I think that's a problem if exposed to SQL. People won't >> understand the hazards and end up using it because its faster or >> somesuch. > > The important question is whether to document the new operator and/or provide > it under a guessable name. If we give the operator a weird name, don't > document it, and put an "internal use only" comment in the catalogs, that is > essentially as good as hiding this feature at the SQL level. > > I'm of two minds on that question. On the one hand, MV maintenance is hardly > the first use case for an identity operator. Any replication system or user > space materialized view implementation might want this. On the other hand, > offering it for the record type exclusively is surprising. It's also > surprising how records with different numbers of dropped columns can be found > identical, even though a record column within the top-level record is not > permitted to vary that way. > > Supposing a decision to document the operator, a second question is whether > "===" is the right name:
I vote to reserve '===' as shorthand for 'IS NOT DISTINCT FROM' and give the binary equality operator a funky name. I would document the operator though. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers