From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Rod Taylor" <rbt(at)zort(dot)ca> |
Cc: | "Hackers List" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_constraint |
Date: | 2002-04-26 15:44:29 |
Message-ID: | 26550.1019835869@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Rod Taylor" <rbt(at)zort(dot)ca> writes:
>> Could we instead insist on a unique name per-table, and make this
>> table's
>> key be (conrelid, conname)? Assigning a number seems quite
>> artificial.
> The only problem with this is that I don't want the rename of a
> constraint to have to fall over into the pg_depend table. pg_depend
> is currently happy with system OIDS or a Relation OID and some unique
> number to represent it -- much as pg_description wouldn't want to know
> the name of the constraint for the ability to add a comment to it.
Good points, but I think those argue for assigning OIDs to constraints
after all. If that is what you want connum for then I have a *big*
problem with it: aren't you assuming that connum will be distinct from
any attribute number that the relation might have? What's going to
enforce that? Besides, the approach doesn't scale to allow other
kinds of objects associated with a relation (just try keeping attnum,
connum, foonum, and barnum from overlapping...).
I had once thought that we could avoid assigning OIDs to rules and
triggers, but learned differently as I got into the implementation.
I'm thinking that constraints will be the same kind of thing; it'll
be a lot easier if you give them OIDs.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-04-26 15:49:19 | Re: Vote totals for SET in aborted transaction |
Previous Message | Lincoln Yeoh | 2002-04-26 15:35:36 | Re: Vote totals for SET in aborted transaction |