On 09/18/2013 09:41 PM, Kevin Grittner wrote: > Dimitri Fontaine <dimi...@2ndquadrant.fr> wrote: >> Kevin Grittner <kgri...@ymail.com> writes: >>> change, but if '1.4' was stored in a column copied into a matview >>> and they later updated the source to '1.40' the increase in >>> accuracy would not flow to the matview. That would be a bug, not a >>> feature. >> Maybe the answer to that use case is to use the seg extension? >> >> http://www.postgresql.org/docs/9.3/interactive/seg.html > You are arguing that we should provide lesser support for numeric > columns (and who knows how many other types) in materialized views > than we do in streaming replication, pg_dump, > suppress_redundant_updates_trigger(), and other places? Why? > >> IOW, colour me unconvinced about that binary-equality opclass use case >> in MatViews. We are trusting the btree equality operator about >> everywhere in PostgreSQL and it's quite disturbing to be told that in >> fact we should not trust it. > Who said we should not trust it? I have said that equality in > PostgreSQL does not mean the two values appear the same or behave > the same in all cases -- the definer of the class gets to determine > how many definitions of equality there are, and which (if any) is > tied to the = operator name. That should not be news to anybody; > it's in the documentation. I'm proposing a second definition of > equality with a different operator name for comparing two records, > without in any way disturbing the existing definition. Basically what proposed === does is "is guaranteed to be equal". If it is not *guaranteed* it is safe to re-evaluate, either using equal or something else.
-- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
