On 2013-09-18 11:06:13 -0500, Merlin Moncure wrote:
> > 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.
I know the feeling, but I don't have a better suggestion either, so...
> 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.
It's an externally exposed API with not easily understandable semantics
that's not actually all that useful outside specific usecases. If we
decide to change it we're creating an API breakage. And we get to deal
with people saying it's broken because they don't understand the
semantics.
That said, I am ok with this if we use strange operator names and
document that the semantics are complicated...
==!!<
==!!<=
...
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services