On Wed, Sep 18, 2013 at 10:59 AM, Stephen Frost <sfrost@snowman.net> wrote:
> * Andres Freund (andres@2ndquadrant.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
