Re: ADD/DROP INHERITS

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: ADD/DROP INHERITS
Date: 2006-06-15 15:19:04
Message-ID: 28182.1150384744@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Greg Stark <gsstark(at)mit(dot)edu> writes:
> So I'm thinking it's better to leave my implementation as is rather than
> reimplement it using the relcache. Or would it be better to use the relcache
> and then when and if it comes to making inherited tables inherit foreign key
> constraints look into adding foreign keys and the deferrable and isdeffered
> flags to the relcache?

Well, it's reasonable to assume that the relcache entries for check
constraints include everything that's semantically meaningful, because
that's what the actual constraint enforcement code looks at. IE, if
we ever did have deferrable check constraints then that flag would get
added to the entries.

However, we don't keep any info about FK constraints in the relcache
(except indirectly via their triggers). At the moment I can't think
of any reason why we should.

If you're happy with the code looking directly at pg_constraint then
I see no reason to change it. I just mentioned the relcache because
I thought you were concerned about the performance of a pg_constraint
search.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2006-06-15 15:57:36 Re: Test request for Stats collector performance improvement
Previous Message Greg Stark 2006-06-15 15:10:05 Re: ADD/DROP INHERITS

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2006-06-15 15:56:43 Re: SQL/XML publishing function experimental patch II
Previous Message Greg Stark 2006-06-15 15:10:05 Re: ADD/DROP INHERITS