On Wed, Sep 18, 2013 at 10:59 AM, Stephen Frost <sfr...@snowman.net> wrote: > * Andres Freund (and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
