On Tue, May 6, 2008 at 7:57 PM, Tom Lane <[EMAIL PROTECTED]> wrote: > "Alex Hunsaker" <[EMAIL PROTECTED]> 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
