Re: WIP: generalized index constraints - Mailing list pgsql-hackers

From Robert Haas
Subject Re: WIP: generalized index constraints
Date
Msg-id 603c8f070909192015y73930137q8fa331bffd205dc2@mail.gmail.com
Whole thread Raw
In response to Re: WIP: generalized index constraints  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: WIP: generalized index constraints
List pgsql-hackers
On Sat, Sep 19, 2009 at 2:51 PM, Jeff Davis <pgsql@j-davis.com> wrote:
> On Sat, 2009-09-19 at 14:05 -0400, Tom Lane wrote:
>> What about them?  It's not clear why you think this requires anything
>> special.
>
> >From a syntax standpoint, I need to represent one operator for every
> index column involved in the constraint. So, if there's a functional
> index on ((a||b)::circle), I clearly can't have an exclusion constraint
> like (a =, b =).
>
> I see two options:
>
>  1. (<expr> <op>), where <expr> is an expression over table attributes
>    that must have the exact signature as the expression for the index.
>  2. (<index_col> <op>), and then read the expression from the index

I was wondering if we couldn't introduce a dummy tuple name similar to
OLD and NEW, called, say, OTHER.  Then instead of writing a =, you
could write a = OTHER.a ... or perhaps a = OTHER.b ... although that
might also open the door to more things than you want to support at
this point.

...Robert


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5
Next
From: Robert Haas
Date:
Subject: Re: Anonymous code blocks