Re: record identical operator - Mailing list pgsql-hackers

From Robert Haas
Subject Re: record identical operator
Date
Msg-id CA+TgmoYJQpjyzgpvdAOJRzYE-HeQ7McnabgYrCEj25LtRAJmuA@mail.gmail.com
Whole thread Raw
In response to Re: record identical operator  (Vik Fearing <vik.fearing@dalibo.com>)
List pgsql-hackers
On Wed, Sep 18, 2013 at 7:29 PM, Vik Fearing <vik.fearing@dalibo.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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Assertions in PL/PgSQL
Next
From: Vik Fearing
Date:
Subject: Dump/Reload broken with relocatable extensions