From: | Rod Taylor <rbt(at)zort(dot)ca> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Scope of constraint names |
Date: | 2002-07-03 00:15:11 |
Message-ID: | 1025655312.232.293.camel@jester |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> One problem I see is that pg_constraint entries can *only* be associated
> with relations; so the table has no way to represent constraints
> associated with domains --- not to mention assertions, which aren't
It's ugly, but one could make the relid 0, and add a typeid which is
non-zero to represent a constraint against a domain. Relation
constraints have typeid 0 and relid as a normal number.
Obviously I prefer unique constraint names mostly for my users. For
some reason they tend to try to make assumptions about a constraint
given the name and have been fooled about what the constraint actually
is more than once due to 'having seen it before elsewhere'.
Is applying a lock on the pg_constraint table really that bad during
creation? Sure, you could only make one constraint at a time -- but
thats the same with relations, types, and a fair number of other things
that are usually created at the same time (or same transaction) as most
constraints will be.
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-07-03 01:03:34 | Re: listen/notify argument (old topic revisited) |
Previous Message | Jeroen T. Vermeulen | 2002-07-02 22:20:51 | Re: Integrating libpqxx |