* Robert Haas (robertmhaas@gmail.com) wrote:
> Your example demonstrates that if a given query can generate two
> different outputs, A and B, based on the same input data, then the
> contents of the materialized view cannot be equal to be A and also
> equal to B. Well, no duh.
Two different outputs based on what *plan* is chosen.
> Of course, you don't need citext, or any other data type with a loose
> notion of equality, to generate that sort of problem:
[...]
> rhaas=# set datestyle = 'german';
> SET
I'm talking about *planner differences* changing the results. If we've
got a ton of cases where a different plan means different output, then
we've got some serious problems. I'd argue that it's pretty darn clear
that datestyle is going to be a *slightly* different animal. My example
doesn't *require* changing any GUCs, it was just expedient for
illustration.
> But I'm still wondering what this is intended to prove.
These types are, to those that use them at least, a known quantity wrt
what you get when using them in GROUP BYs, JOINs, etc. You're trying
to 'fix' something that isn't really broken and you're only doing it
half-baked anyway because your 'fix' isn't going to actually make these
types produce consistent results.
> There are an
> infinite number of ways to write queries that produce different
> results, and I think we all know that materialized views aren't going
> to hold up very well if given such queries. That seems a poor excuse
> for not fixing the cases that can be made to work.
New operators are not without cost, I don't think it's a good idea to
expose our internal binary representations of data out to the SQL level,
and the justification for adding them is that they solve a case that
they don't.
Thanks,
Stephen