Re: BUG #6024: pg_dump won't dump ALTERed inherited fields

From: "P(dot) Christeas" <p_christ(at)hol(dot)gr>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #6024: pg_dump won't dump ALTERed inherited fields
Date: 2011-05-12 16:32:04
Message-ID: 201105121932.06658.p_christ@hol.gr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Thursday 12 May 2011, you wrote:
> "Panos Christeas" <xrg(at)linux(dot)gr> writes:
> > CREATE TABLE test1(id SERIAL PRIMARY KEY,
> > name VARCHAR(20) NOT NULL);
> > CREATE TABLE test2(description TEXT) INHERITS(test1);
> > ALTER TABLE test2 ALTER name DROP NOT NULL;
> >
> > pg_dump that.
> > The dump will still have "not null" constraint at test2.name.
>
> This isn't really a pg_dump deficiency. The bug is that we let you do
> that ALTER. Inherited constraints shouldn't be droppable, and indeed
> are not droppable except in the single case of NOT NULL. This is on the
> to-fix list --- in fact there was a patch submitted for it last year,
> although it got returned for rework and we've not seen it again yet.
>

That's fine for me. Just as long as pg_dump is consistent* with what the schema
can be.

Perhaps, some errata or warning in the documentation would do, too. (is there
any, already? )

* however, do consider that old servers will still be able to hold such
inconsistent (I admit it) data; we can't apply that behavior to them.

--
Say NO to spam and viruses. Stop using Microsoft Windows!

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Daniel Grace 2011-05-12 17:28:49 Re: BUG #6005: ALTER ROLE ... VALID UNTIL 'infinity' crashes postmaster on a fresh install
Previous Message Tom Lane 2011-05-12 15:24:13 Re: BUG #6024: pg_dump won't dump ALTERed inherited fields