On Tue, Sep 24, 2013 at 7:14 AM, Stephen Frost <sfrost@snowman.net> wrote:
>> 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.
I'm completely confused, here. What's so special about planner
differences? Obviously, there are tons of queries that can produce
different results based on planner differences, but materialized views
didn't create that problem and they aren't responsible for solving it.
Also, even restricting ourselves to planner differences, there's no
particular link between the behavior of the type's equality operator
and whether or not the query always produces the same results. For
example, let's consider good old text.
rhaas=# create table tag_data (id integer, tag text, userid text,
primary key (id, tag));
CREATE TABLE
rhaas=# insert into tag_data values (1, 'foo', 'tom'), (1, 'bar',
'dick'), (2, 'baz', 'harry');
INSERT 0 3
rhaas=# select id, string_agg(tag||':'||userid, ', ') tags from
tag_data group by 1;id | tags
----+------------------- 1 | foo:tom, bar:dick 2 | baz:harry
(2 rows)
rhaas=# set enable_seqscan=false;
SET
rhaas=# select id, string_agg(tag||':'||userid, ', ') tags from
tag_data group by 1;id | tags
----+------------------- 1 | bar:dick, foo:tom 2 | baz:harry
(2 rows)
Now texteq() is just a glorified version of memcmp(), so what does
this complaint possibly have to do with Kevin's patch, or even
materialized views in general?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
