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.
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