From: | Hannu Krosing <hannu(at)2ndQuadrant(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Kevin Grittner <kgrittn(at)ymail(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, 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 21:49:50 |
Message-ID: | 523A1FFE.9060305@2ndQuadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 09/18/2013 07:53 PM, Stephen Frost wrote:
>
> I'm really curious about your thoughts on unique indexes then. Should
> two numerics which are the same value but different byte
> representations be allowed in a unique index?
You could have multiple btree opclasses defined which would enforce
different kind of "uniqueness"
For example you could have an opclass which considers two strings
"equal" if four first bytes are equal.
If you would create an unique index using that opclass you could not
have both "industrial" and
"induction" as primary keys as the same time, as the unique index would
consider them equal.
But you would still want to see the change in your matview after you do
UPDATE mytable set id = 'industrial' where id = 'induction';
Cheers
--
Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic OÜ
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2013-09-18 22:20:21 | Dead code or buggy code? |
Previous Message | Hannu Krosing | 2013-09-18 21:40:17 | Re: record identical operator |