Skip site navigation (1) Skip section navigation (2)

Re: Backend misfeasance for DEFAULT NULL

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Backend misfeasance for DEFAULT NULL
Date: 2007-10-28 17:21:49
Message-ID: 1193592109.4242.707.camel@ebony.site (view raw or flat)
Thread:
Lists: pgsql-hackers
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


In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2007-10-28 18:13:04
Subject: Re: Backend misfeasance for DEFAULT NULL
Previous:From: Oleg BartunovDate: 2007-10-28 17:01:01
Subject: Re: BK-Tree Implementation on top of GiST

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group