On Tue, May 6, 2008 at 7:57 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Alex Hunsaker" <badalex@gmail.com> writes:
> > [ patch to fix behavior of inherited constraints ]
>
> Looking over this patch, I see that it introduces a syscache on
> pg_constraint (conrelid, conname), which requires a unique index
> underlying it. This is not workable because domain constraint
> entries in pg_constraint will have conrelid = 0. The index would
> therefore have the effect of forbidding the same constraint name
> to be used for two different domains' constraints.
>
> The fact that pg_constraint stores both relation and domain constraints
> is a fairly ugly crock, not least because it means there is no natural
> primary key for the table. I've thought for some time that we should
> split it into two catalogs. (We could provide a union view to avoid
> breaking clients that look at it.) However it seems a bit ill-advised
> to tackle that change as an essential part of this patch.
>
> Was there any particularly strong reason why you introduced the syscache
> instead of working with the available indexes?
>
> regards, tom lane

None other than the syscache stuff was way easier to work with than
the 25-50 lines of boilerplate code that Ill need everywhere I use
CONSTRNAME. (see the hunk to MergeAttributesIntoExistsing for an
example of what i mean). Not a big deal though, NikhilS was not sure
about those changes in the first place.

Ill just rip it out for now. Patch forthcoming.

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