Prev: corrupted double-linked list
Next: Timestamp to time_t
From: Peter Eisentraut on 21 Sep 2009 09:30
On Sun, 2009-09-20 at 10:08 -0700, Jeff Davis wrote:
> On Sun, 2009-09-20 at 13:01 -0400, Tom Lane wrote:
> > The current infrastructure for deferred uniqueness requires that the
> > thing actually be a constraint, with an entry in pg_constraint that
> > can carry the deferrability options. So unless we want to rethink
> > that, this might be a sufficient reason to override my arguments
> > about not wanting to use CONSTRAINT syntax.
>
> Ok. Using the word EXCLUSION would hopefully guard us against future
> changes to SQL, but you know more about the subtle dangers of language
> changes than I do.
>
> So, do I still omit it from information_schema?

I would say yes.

Overall, I think this terminology is pretty good now. We could say,
PostgreSQL has a new constraint type, exclusion constraint. It shares
common properties with other constraint types, e.g., deferrability (in
the future), ADD/DROP CONSTRAINT, etc. But because the standard does
not describe exclusion constraints, they are not listed in the
information schema.


--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

First  |  Prev  | 
Pages: 2 3 4 5 6 7 8 9 10 11 12
Prev: corrupted double-linked list
Next: Timestamp to time_t