Re: [PATCHES] [badalex@gmail.com: Re: [BUGS] Problem identifying constraints which should not be inherited]

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.