Re: Bug in 8.2 (&8.1) dump & restore

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Scott Ribe <scott_ribe(at)killerbytes(dot)com>
Cc: "pgsql-general postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Bug in 8.2 (&8.1) dump & restore
Date: 2007-01-04 20:32:31
Message-ID: 26459.1167942751@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Scott Ribe <scott_ribe(at)killerbytes(dot)com> writes:
> create database test;
> \c test
> create table base (foo int not null);
> create table derived () inherits (base);
> alter table derived alter foo drop not null;
> insert into derived values(null);

> Dump it, and the dump will not include any command to drop the not null
> constraint on derived.foo, so restore will fail.

Actually, the bug there is that ALTER TABLE lets you set up a
self-inconsistent inheritance hierarchy. The above should be illegal
because it would mean that "select foo from base" could return nulls,
contradicting the clear definition of the table.

We've been talking about fixing that, but it'll probably take catalog
changes (to be able to track which constraints were inherited from a
parent table) so this isn't ever going to be enforced by any existing
release.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message John McCawley 2007-01-04 20:39:14 Re: Any form of connection-level "session variable" ?
Previous Message Tom Lane 2007-01-04 20:26:16 Re: Any form of connection-level "session variable" ?