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-10 17:00:38
Message-ID: 924.1149958838@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Greg Stark <gsstark(at)mit(dot)edu> writes:
> So should I set up a nested scan, essentially implementing a nested loop? or
> should I gather together all the children in a list?

I'd use the predigested form of the constraints attached to the Relation
tupledescs, cf. RelationBuildTupleDesc, equalTupleDescs.  It might be
worth refactoring equalTupleDescs so you could share code --- ISTM what
you're trying to implement is something like a "subsetTupleDesc".

> And are there any other fields of pg_constraint that I should be checking for
> matches in? Do we care if a parent table has a non-deferrable constraint and
> the child has a deferrable one, or if the parent's is deferred by default and
> the child isn't?

I don't believe those attributes mean anything for check constraints
ATM, but you may as well compare them anyway.  If we ever do implement
them then it'd be reasonable to expect parent and child to have
identical settings.

> Also, it seems to me that LIKE ought to copy constraints or at least have an
> option to.

What does the spec say about that?

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Greg StarkDate: 2006-06-10 17:06:58
Subject: Re: [PATCHES] ADD/DROP INHERITS
Previous:From: Michael GlaesemannDate: 2006-06-10 16:49:49
Subject: Re: Ranges for well-ordered types

pgsql-patches by date

Next:From: Greg StarkDate: 2006-06-10 17:06:58
Subject: Re: [PATCHES] ADD/DROP INHERITS
Previous:From: Greg StarkDate: 2006-06-10 16:43:17
Subject: Re: ADD/DROP INHERITS

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