Re: [PATCHES] [badalex@gmail.com: Re: [BUGS] Problem identifying constraints which should not be inherited] - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCHES] [badalex@gmail.com: Re: [BUGS] Problem identifying constraints which should not be inherited]
Date
Msg-id 28421.1210125450@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCHES] [badalex@gmail.com: Re: [BUGS] Problem identifying constraints which should not be inherited]  (NikhilS <nikkhils@gmail.com>)
Responses Re: [PATCHES] [badalex@gmail.com: Re: [BUGS] Problem identifying constraints which should not be inherited]  ("Alex Hunsaker" <badalex@gmail.com>)
List pgsql-hackers
"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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: CONSTROID syscache vs relcache flushes
Next
From: Tom Lane
Date:
Subject: Re: [PATCHES] column level privileges