Re: record identical operator

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Kevin Grittner <kgrittn(at)ymail(dot)com>, Hannu Krosing <hannu(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: record identical operator
Date: 2013-09-18 16:06:13
Message-ID: CAHyXU0wQRGdmU6X4H=1C14w8uuXN1kKzBKd8tgMRAdbBczZWOw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Sep 18, 2013 at 10:59 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> * Andres Freund (andres(at)2ndquadrant(dot)com) wrote:
>> I think this really needs to have an obscure name. Like ==!!== or
>> somesuch (is equal very much, but doesn't actually test for equality ;))
>
> hah.
>
>> > What the heck is the use case for this being a user-oriented, SQL
>> > operator..?
>>
>> The materalized view code uses generated SQL, so it has to be SQL
>> accessible. And it needs to be an operator because the join planning
>> code requires that :(
>
> Ugh. This feels like a pretty ugly hack to deal with that. I haven't
> got any magical wand to address it, but making an SQL operator for 'are
> these really the same bytes' to deal with what is essentially
> implementation detail is _very_ grotty.

Having matviews using SQL expressible features is a *good* thing.
Having a user accessible operator is nice to have (if for no other
reason than to allow testing for which matview rows would be
refreshed). I just don't understand what all the fuss is about except
to make sure not to utilize an operator name that is better suited for
other purposes.

merlin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dimitri Fontaine 2013-09-18 16:11:34 Re: Where to load modules from?
Previous Message Stephen Frost 2013-09-18 16:05:32 Re: record identical operator