On Sun, 2007-10-28 at 12:44 -0400, Tom Lane wrote: > 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;
Seems more like an unwanted looseness in the meaning of an ALTER TABLE .. INHERIT to me. I'd prefer it if we added some extra clauses to ALTER TABLE: [ { INCLUDING | EXCLUDING } { DEFAULTS | CONSTRAINTS | INDEXES } ] > 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. Agreed. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---------------------------(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