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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Alex Hunsaker" <badalex(at)gmail(dot)com>
Cc: NikhilS <nikkhils(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCHES] [badalex@gmail.com: Re: [BUGS] Problem identifying constraints which should not be inherited]
Date: 2008-05-07 01:57:30
Message-ID: 28421.1210125450@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

"Alex Hunsaker" <badalex(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-05-07 02:19:02 Re: [PATCHES] column level privileges
Previous Message Tom Lane 2008-05-07 01:24:50 CONSTROID syscache vs relcache flushes

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2008-05-07 02:34:17 Re: [HACKERS] [GENERAL] psql \pset pager
Previous Message Tom Lane 2008-05-07 00:57:48 Re: column level privileges