Re: [GENERAL] I think this is a BUG? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [GENERAL] I think this is a BUG?
Date
Msg-id 766.1209056263@sss.pgh.pa.us
Whole thread Raw
In response to Re: [GENERAL] I think this is a BUG?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [GENERAL] I think this is a BUG?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
I wrote:
> I think the bug here is that ADD COLUMN NOT NULL has to fail if
> there's not a default expression supplied (except maybe we could
> allow it if the table contains no rows).  ISTM we got this right
> in the past, wonder why it's not working now ...

Hm, we do get it right if PRIMARY KEY isn't in the picture:

regression=# create table t1 (f1 int);
CREATE TABLE
regression=# insert into t1 values(1);
INSERT 0 1
regression=# alter table t1 add column f2 int not null;
ERROR:  column "f2" contains null values

The above is correct, but if I now try

regression=# alter table t1 add column f2 int primary key;
NOTICE:  ALTER TABLE / ADD PRIMARY KEY will create implicit index "t1_pkey" for table "t1"
ALTER TABLE
regression=# \d t1     Table "public.t1"Column |  Type   | Modifiers 
--------+---------+-----------f1     | integer | f2     | integer | not null
Indexes:   "t1_pkey" PRIMARY KEY, btree (f2)

So somehow the constraint-validation code isn't getting applied in
this case.  I suspect you'll find it's a pretty localized fix.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Brendan Jurd"
Date:
Subject: Re: [GENERAL] I think this is a BUG?
Next
From: Bruce Momjian
Date:
Subject: Re: 8.3 / 8.2.6 restore comparison