Tom Lane <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> 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.
Advertising
I've spent more time absorbing relcache.c and I see now that there is in fact
a ccname array that contains the constraint names.
The relcache does not however contain the deferrable and isdeferred flags
which as you point out don't mean much for check constraints. But you said I
should be checking those. Going with the relcache would mean not being able to
check them.
Going with the relcache would also mean I wouldn't be able to easily add
foreign key constraints. I had hoped to add foreign key constraints to the
list of things that inherited tables copy and checking for them in
AddInherits.
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?
> It might be worth refactoring equalTupleDescs so you could share code ---
> ISTM what you're trying to implement is something like a "subsetTupleDesc".
I still don't see how there's any refactoring possible here. I could move the
code into a function in tupdesc.c but then it would mean an entirely redundant
loop to bump attinhcount.
--
greg
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
