On Sun, Sep 15, 2013 at 6:49 PM, Noah Misch <noah@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 <andres@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