On 09/18/2013 09:41 PM, Kevin Grittner wrote:
> Dimitri Fontaine <dimitri@2ndQuadrant.fr> wrote:
>> Kevin Grittner <kgrittn@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Ü