* Robert Haas (robertmh...@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
signature.asc
Description: Digital signature