I wrote:
> ... 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.

I did this (see attached patch) and got an interesting failure in the
domain regression test.  That test has

create domain ddef1 int4 DEFAULT 3;
create table defaulttest
		...
            , col5 ddef1 NOT NULL DEFAULT NULL
		...
insert into defaulttest default values;

and the 'expected' result is that this succeeds and inserts 3; meaning
that the domain default overrides the explicit per-column specification.
But with the patch it fails with "null value in column "col5" violates
not-null constraint".

AFAICS this is a flat-out bug too, since the per-column default should
override the domain's default; that's certainly how it works for any
non-null column default value.  But I wasn't expecting any regression
failures with this patch.  Is it OK to change this behavior?  Should I
back-patch, or not?

(BTW, the reason this is exposed is that when a domain is involved, the
apparently plain NULL is really a CoerceToDomain operation, which the
new test sees as not being the same as a plain null constant; correctly
so, if you ask me, since CoerceToDomain might or might not reject a
null.)

			regards, tom lane

In response to

• Backend misfeasance for DEFAULT NULL at 2007-10-28 16:44:04 from Tom Lane

Responses

• Re: Backend misfeasance for DEFAULT NULL at 2007-10-28 22:34:25 from Gregory Stark

pgsql-hackers by date

Next:	From: Josh Berkus	Date: 2007-10-28 21:54:45
	Subject: Re: Opportunity for a Radical Changes in Database Software
Previous:	From: Tom Lane	Date: 2007-10-28 19:43:21
	Subject: Re: Backend misfeasance for DEFAULT NULL