Re: [COMMITTERS] pgsql: Remove arbitrary ALTER TABLE .. ADD COLUMN restriction.

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [COMMITTERS] pgsql: Remove arbitrary ALTER TABLE .. ADD COLUMN restriction.
Date: 2011-01-26 21:34:06
Message-ID: AANLkTinzeZiXE7VQ3xdfdpaxVAkt5_JJFi+auBAM=OY-@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On Wed, Jan 26, 2011 at 4:20 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> Considering the number of OTHER places we'd have to break backward
>> compatibility, one more wouldn't bother me any, but apparently that's
>> just me.
>
> Well, again, it'd be all right with me if we were going to get any
> meaningful increment in functionality out of it, but we aren't.  If you
> add the column and the default in separate steps, you get the same
> result and all the behavior is spec-compliant.
>
> There's some history here that you may not be familiar with --- we used
> to have exactly this bug in regards to the mainline ALTER TABLE case.
> Observe the results in PG 7.1:
>
> regression=# create table foo(f1 int);
> CREATE
> regression=# insert into foo values(1);
> INSERT 3151259 1
> regression=# insert into foo values(2);
> INSERT 3151260 1
> regression=# alter table foo add column f2 int default 2;
> ALTER
> regression=# select * from foo;
>  f1 | f2
> ----+----
>  1 |
>  2 |
> (2 rows)
>
> In 7.2 through 7.4 the ALTER failed instead:
> regression=# alter table foo add column f2 int default 2;
> ERROR:  Adding columns with defaults is not implemented.
>        Add the column, then use ALTER TABLE SET DEFAULT.
>
> and by 8.0 we'd finally made it work per spec.  But we got lots of flak
> meanwhile from people who'd gotten used to the old behavior.  So those
> of us who were around then aren't eager to repeat that.  The code you're
> complaining about now was put in only a month after we got that problem
> fixed, so the issue was plenty fresh in mind at the time.

Yeah, I wasn't aware of that. I'll go revert, but I think I'll also
add a big fat comment, because this is entirely non-obvious,
especially because we don't disallow the cases SET NOT NULL and ADD
table_constraint, which have the same darn problem. Aren't people who
are used to those cases going to be pretty surprised too?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2011-01-26 22:04:59 Re: [COMMITTERS] pgsql: Remove arbitrary ALTER TABLE .. ADD COLUMN restriction.
Previous Message Bruce Momjian 2011-01-26 21:21:53 pgsql: Per Peter E, use 'kB' for kilobyte, not 'K'.

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2011-01-26 21:38:31 Re: .gitignore patch for coverage builds
Previous Message Robert Haas 2011-01-26 21:26:25 Re: ALTER TYPE 3: add facility to identify further no-work cases