| From: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
|---|---|
| To: | Stephen Frost <sfrost(at)snowman(dot)net>, Steve Singer <steve(at)ssinger(dot)info> |
| Cc: | 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 18:08:54 |
| Message-ID: | 1379527734.20180.YahooMailNeo@web162902.mail.bf1.yahoo.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> I don't think that means we should change our definition of
> equality to generally be "are the bytes the same"- clearly that'd
> lead to incorrect behavior in the NUMERIC case.
Nobody is talking in any way, shape, or form about changing our
concept of what is "equal". We're talking about recognizing that
in PostgreSQL "equal" does *not* mean "the same". If we used the
equal concept for determining what has changed, if someone was
tracking numeric data without precision and scale so that they
could track accuracy (by storing the correct number of decimal
positions) the accuracy could not be replicated to a materialized
view. Of course, streaming replication would replicate the
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.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Fetter | 2013-09-18 18:29:22 | Please mark new patches on the next CF |
| Previous Message | Heikki Linnakangas | 2013-09-18 18:07:00 | Re: UTF8 national character data type support WIP patch and list of open issues. |