Re: record identical operator

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Vik Fearing <vik(dot)fearing(at)dalibo(dot)com>
Cc: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Kevin Grittner <kgrittn(at)ymail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Steve Singer <steve(at)ssinger(dot)info>, Andres Freund <andres(at)2ndquadrant(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-19 19:20:38
Message-ID: CA+TgmoYJQpjyzgpvdAOJRzYE-HeQ7McnabgYrCEj25LtRAJmuA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Sep 18, 2013 at 7:29 PM, Vik Fearing <vik(dot)fearing(at)dalibo(dot)com> wrote:
> On 09/19/2013 12:55 AM, Dimitri Fontaine wrote:
>>> We have, as a community, gone to a fair amount of trouble to make
>>> > the concept of equality pluggable and allow multiple types of
>>> > equality per type. To me it seems the perfect tool to solve this
>>> > problem. Why the fuss?
>> Because I don't understand why you need another equality than the
>> default btree one, certainly.
>
> Basically because 'word'::citext and 'Word'::citext are the same to your
> brain but not to your eyeballs.
>
> Unique indexes, for example, only need to please your brain. Matviews
> need to please your eyeballs.

Right, and well said.

It's perfectly reasonable to want a "unique" index that doesn't allow
both "Kevin O'leary" and "Kevin O'Leary" to be listed in the
"irish_names" table, but it's also perfectly reasonable to want to
remember that the user who entered the data spelled it the second way
and not the first. And it's also reasonable to want any corrections
made to the table to propagate to any materialized views defined over
it.

The fact that we have multiple concepts of equality can be confusing,
but it's not for no reason, and we're not the only database or
programming language to have such a concept.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Vik Fearing 2013-09-19 20:50:51 Dump/Reload broken with relocatable extensions
Previous Message Robert Haas 2013-09-19 19:09:20 Re: Assertions in PL/PgSQL