| From: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
|---|---|
| To: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
| Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Steve Singer <steve(at)ssinger(dot)info>, Andres Freund <andres(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Hannu Krosing <hannu(at)2ndquadrant(dot)com>, "pgsql-hackers\(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: record identical operator |
| Date: | 2013-09-18 19:19:36 |
| Message-ID: | m24n9i6ipj.fsf@2ndQuadrant.fr |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Kevin Grittner <kgrittn(at)ymail(dot)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
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.
Would it make sense for you to produce a patch without the extra
operators, behavior, opclass and opfamily here so that we can focus on
the MatView parts of it?
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Grittner | 2013-09-18 19:41:31 | Re: record identical operator |
| Previous Message | Kevin Grittner | 2013-09-18 18:40:49 | Re: record identical operator |