Re: Deferred partial/expression unique constraints

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org, Josh Berkus <josh(at)agliodbs(dot)com>
Subject: Re: Deferred partial/expression unique constraints
Date: 2011-07-22 20:35:43
Message-ID: 1311366943.7322.2.camel@vanquo.pezone.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On ons, 2011-07-13 at 11:26 -0400, Tom Lane wrote:
> Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> writes:
> >>> On 7/12/11 9:46 AM, Andres Freund wrote:
> >>>> I guess $subject wasn't implemented because plain unique indexes aren't
> >>>> represented in pg_constraint and thus do not have a place to store
> >>>> information about being deferred?
>
> > I agree that expressing that using a UNIQUE constraint would perhaps
> > be more intuitive, but it would be new non-SQL-spec syntax that AFAICS
> > wouldn't actually add any new functionality.
>
> Our standard reason for not implementing UNIQUE constraints on
> expressions has been that then you would have a thing that claims to be
> a UNIQUE constraint but isn't representable in the information_schema
> views that are supposed to show UNIQUE constraints. We avoid this
> objection in the current design by shoving all that functionality into
> EXCLUDE constraints, which are clearly outside the scope of the spec.

I have never heard that reason before, and I think it's a pretty poor
one. There are a lot of other things that are not representable in the
information schema.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2011-07-22 20:39:03 Re: cataloguing NOT NULL constraints
Previous Message Greg Smith 2011-07-22 20:25:34 Re: Policy on pulling in code from other projects?