On Wed, Feb 22, 2006 at 10:11:51AM -0500, Tom Lane wrote:
> Chris Dunlop <chris@onthe.net.au> writes:
>> E.g. using the script below, the 'bar.f1' column in the 'new'
>> database ends up with a 'not null' constraint that isn't present
>> in the 'orig' database.
>
>> create table foo (f1 integer not null);
>> create table bar () inherits(foo);
>> alter table bar alter column f1 drop not null;
>
> The general consensus is that the above should be illegal, ie,
> the ALTER should have been rejected. Otherwise you would have
> a situation where a "SELECT FROM foo" could return nulls,
> violating the very clear contract of that table. We have not
> got around to enforcing this yet, but it's on the TODO. I
> don't see it as a pg_dump bug that it's unable to reproduce an
> invalid situation.
OK, thanks for the response Tom. That makes sense (although it
could also be argued the contract is maintained using the "ONLY"
clause - but I imagine this has been beaten to death on the
lists already).
We'll redo our schema and program logic to be prepared for this
change if/when it comes about. At least this will allow us to
correctly restore this one database without fooling with the
dump file!
One way or the other, I think either allowing the inherited
constraints to be dropped, or the inability of pg_dump to
correctly dump the resulting schema, should be considered a bug
rather than a lacking feature, as the current situation results
in problematical restores. Is there a "known bugs" list?
Cheers,
Chris.