Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-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

pgsql-hackers by date

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

pgsql-patches by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group