Greg Stark <[EMAIL PROTECTED]> writes:
> I'm a bit confused about what pg_depends entries would be necessary then. If
> there's something like this there:
> Child Table <--(AUTO)-- pg_inherit entry --(NORMAL)-> Parent Table
I think that would work, but it seems pretty baroque. pg_inherit
entries are not separately accessible SQL objects; not in the sense
that, say, a table's rowtype is. I think it'd be just about as easy
to leave the catalog definitions as-is and just manually drop the
child-to-parent pg_depend entry. This would certainly be less code than
all the infrastructure needed to add pg_inherit entries as a separate
kind of dependency object.
I also note that to go in this direction, pg_inherits would need to add
an OID column, and an index on it.
BTW ... are you intending to renumber inhseqno entries of remaining
pg_inherits items after DROP INHERITS? Which seqno will be assigned
by ADD INHERITS? This seems like another area in which DROP/ADD will
not be a complete no-op.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
