Re: Inheritance problem when restoring db

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Sebastjan Trepca" <trepca(at)gmail(dot)com>
Cc: "Postgres General" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Inheritance problem when restoring db
Date: 2007-10-28 15:46:57
Message-ID: 29166.1193586417@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"Sebastjan Trepca" <trepca(at)gmail(dot)com> writes:
> This is how to reproduce this issue:
> ...
> inh_test=# alter table capitals inherit cities;

Fascinating. pg_dump is almost smart enough to get this right, except
that what it spits out is

ALTER TABLE capitals ALTER COLUMN id SET DEFAULT nextval('capitals_id_seq'::regclass);
...
ALTER TABLE cities ALTER COLUMN id SET DEFAULT nextval('cities_id_seq'::regclass);

and since it already declared capitals as inheriting from cities, the
second command descends the inheritance tree and replaces the local
default for capitals.

What we apparently must do is add a dependency relation within pg_dump
to cause these two commands to be emitted in the other order. I briefly
considered making these sorts of ALTERs be ALTER TABLE ONLY, but if we
go that route we will be unable to correctly restore the inherited vs
not-inherited property of default expressions. (Not that the system
tracks that currently, but I think there were proposals on the table
to do so.)

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2007-10-28 16:35:03 Re: select count() out of memory
Previous Message Perry Smith 2007-10-28 14:55:58 Re: I want to search my project source code