Re: ADD/DROP INHERITS

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: ADD/DROP INHERITS
Date: 2006-06-08 19:00:55
Message-ID: 87k67rjwuw.fsf@stark.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

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

I assigned inhseqno to be max(inhseqno)+1. I was already scanning the parents
to check for duplicate parents so I just accumulated a maximum seqno at the
same time.

It's not a precise noop in database internal data structures, but I don't see
any user-visible effects switching around seqnos would have. But maybe there's
something I don't know about?

The actual order only seems to be significant in that it affects the ordering
of inherited columns. But that's already thrown to the wind as soon as you
allow adding new parents anyways. I'm just matching by name regardless of
position. And in any case that is only going to match the original ordering of
the original sequno ordering.

I did wonder whether it was kosher to leave holes.

--
greg

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-06-08 19:01:26 Re: Ending EXPLAIN ANALYZE early (was Re: That EXPLAIN ANALYZE patch still needs work)
Previous Message Andrew Dunstan 2006-06-08 18:54:35 Re: [PATCHES] drop if exists remainder