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

Backend misfeasance for DEFAULT NULL

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Backend misfeasance for DEFAULT NULL
Date: 2007-10-28 16:44:04
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
While poking at the complaint reported here:
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.


			regards, tom lane


pgsql-hackers by date

Next:From: Oleg BartunovDate: 2007-10-28 17:01:01
Subject: Re: BK-Tree Implementation on top of GiST
Previous:From: Florian WeimerDate: 2007-10-28 13:29:22
Subject: Re: BK-Tree Implementation on top of GiST

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