"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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
