While poking at the complaint reported here:
http://archives.postgresql.org/pgsql-general/2007-10/msg01484.php
I realized that there is a related issue for null defaults. Consider
create table p (f1 int default 0);
create table c (f1 int);
alter table c inherit p;
At this point, c.f1 has no default, or NULL default if you prefer.
However, pg_dump dumps this configuration as
create table p (f1 int default 0);
create table c (f1 int) inherits (p);
so after a reload c.f1 will have default 0 because it'll inherit that
from p.
I tried to fix this by having pg_dump insert an explicit DEFAULT NULL
clause for c.f1, which turned out to be not too hard, but on testing
it did nothing at all --- c.f1 still reloaded with default 0!
Poking into it, I find that it seems to be another case of the lesson
we should have learned some time ago: embedding semantic knowledge in
gram.y is usually a Bad Idea. gram.y "knows" that it can throw away
DEFAULT NULL --- see the exprIsNullConstant() uses therein. So the
clause never makes it to the place in tablecmds.c where we consider
whether to adopt inherited defaults or not.
ISTM this is a backend bug: if I tell it DEFAULT NULL, by golly I
should get DEFAULT NULL. I propose stripping out gram.y's special
hack for this, and preserving the efficiency of the case by
inserting a test very much later to see if the expression is just
a NULL constant. Maybe AddRelationRawConstraints is the right place.
Comments?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
