| 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: | Whole Thread | Raw Message | 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 |