Re: ADD/DROP INHERITS - Mailing list pgsql-hackers

From Tom Lane
Subject Re: ADD/DROP INHERITS
Date
Msg-id 29906.1149793719@sss.pgh.pa.us
Whole thread Raw
In response to Re: ADD/DROP INHERITS  (Greg Stark <gsstark@mit.edu>)
Responses Re: ADD/DROP INHERITS  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
Greg Stark <gsstark@mit.edu> writes:
> 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?

It'll affect the order in which pg_dump lists the parents, which will
affect the order in which the columns are created on dump and reload.
(Or at least it ought to ... right offhand I don't see anything in the
pg_dump source code that ensures the original order is preserved.  This
may be a pg_dump bug.)

> I did wonder whether it was kosher to leave holes.

Not sure.  I don't offhand see anything that requires the numbers to be
consecutive.

If you don't compact out the holes during DROP, then ADD could use the
rule of "first unused number" instead of max+1.  This would ensure
DROP/ADD is a no-op for simple cases in which you only unlink from one
parent.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "A.M."
Date:
Subject: Re: Ending EXPLAIN ANALYZE early (was Re: That EXPLAIN
Next
From: Tom Lane
Date:
Subject: Re: Running a query twice to ensure cached results.