Greg Stark [EMAIL PROTECTED] 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
Tom Lane [EMAIL PROTECTED] writes:
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.
I'm not concerned with the performance
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,
Greg Stark [EMAIL PROTECTED] writes:
I also haven't checked the constraint name. To do so it would make sense to
use a small hash table.
No, it'd make sense to use strcmp(). It's unlikely that there will be
enough constraints attached to any one table to justify use of any but
the
Tom Lane [EMAIL PROTECTED] writes:
Greg Stark [EMAIL PROTECTED] writes:
I also haven't checked the constraint name. To do so it would make sense
to
use a small hash table.
No, it'd make sense to use strcmp(). It's unlikely that there will be
enough constraints attached to any
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,
Tom Lane [EMAIL PROTECTED] writes:
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.
I'm not sure. Does it have to
This is where I am with the ADD/DROP INHERITS patch now.
1) The syntax is:
ALTER TABLE child INHERIT parent
ALTER TABLE child NO INHERIT parent
no new reserved words, no conflicts, no complicated grammar productions in
gram.y to confuse people in the future.
2) Dependencies are
