From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Backend misfeasance for DEFAULT NULL |
Date: | 2007-10-28 21:12:45 |
Message-ID: | 7220.1193605965@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
Attachment | Content-Type | Size |
---|---|---|
unknown_filename | text/plain | 10.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2007-10-28 21:54:45 | Re: Opportunity for a Radical Changes in Database Software |
Previous Message | Tom Lane | 2007-10-28 19:43:21 | Re: Backend misfeasance for DEFAULT NULL |