Re: Best way to use indexes for partial match at

From: Scott Marlowe <smarlowe(at)g2switchworks(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Andrus <eetasoft(at)online(dot)ee>, pgsql-general(at)postgresql(dot)org
Subject: Re: Best way to use indexes for partial match at
Date: 2005-11-10 17:46:04
Message-ID: 1131644764.3554.93.camel@state.g2switchworks.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, 2005-11-10 at 11:27, Peter Eisentraut wrote:
> Scott Marlowe wrote:
> > Ya know, this brings up an interesting question, would it be feasible
> > to allow for a function of somekind to be applied as an argument to a
> > primary key declaration?
>
> You would have to guarantee somehow that the function is a one-to-one
> mapping, in order not to destroy the integrity of the primary key
> constraint. I cannot think of any useful functions that fulfill this
> criterion.

No, I wouldn't think one to one would be necessary. If you had a
primary key that was case insensitive, for example, it would not map one
to one. It would, in fact, be MORE greedy about matching, so that you
could not have both a "Peter Eisentraut" and a "peter eisentraut" in the
same table.

While I could easily add a unique on table (lower(namefield)) to get
this, being able to use a lower() or some other function would be very
useful. I don't see one to one being necessary, it just needs to be
consistent.

>
> > It would certainly be useful for character
> > type pks in non-C locales.
>
> I don't see how.

By only having to maintain one index on a large table instead of having
a PK AND a separate unique index for these kinds of cases.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Scott Frankel 2005-11-10 17:52:45 save history error, ignorable?
Previous Message Peter Eisentraut 2005-11-10 17:29:39 Re: Best way to use indexes for partial match at