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

Re: Backend misfeasance for DEFAULT NULL

From: Gregory Stark <stark(at)enterprisedb(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 18:14:44
Message-ID: 874pgbyuln.fsf@oxford.xeocode.com (view raw or flat)
Thread:
Lists: pgsql-hackers
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> 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?

Well if there's a convenient later place to add the check then sure. Will it
mean pg_dump will have to put DEFAULT NULL everywhere though? Or can it detect
that it's an inherited table where the default doesn't match?

Perhaps it should be even later and we should store the NULL default in the
catalog but filter it out when we build the relcache? Then pg_dump wouldn't
need any special intelligence to detect when the default doesn't match the
parent

-- 
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2007-10-28 19:43:21
Subject: Re: Backend misfeasance for DEFAULT NULL
Previous:From: Tom LaneDate: 2007-10-28 18:13:04
Subject: Re: Backend misfeasance for DEFAULT NULL

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