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