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: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: ADD/DROP INHERITS
Date: 2006-06-08 18:44:44
Message-ID: 29659.1149792284@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Stark <gsstark(at)mit(dot)edu> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2006-06-08 18:47:56 Re: [PATCHES] drop if exists remainder
Previous Message Andrew Dunstan 2006-06-08 18:39:55 Re: [HACKERS] drop if exists remainder