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

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 16:33:12
Message-ID: AANLkTikZt0OfATUwb3YYafUYYsWJYUuLSVAA62kHnSG9@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
On Wed, Jan 26, 2011 at 11:05 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Wed, Jan 26, 2011 at 10:36 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> This is not an "arbitrary restriction" because according to the SQL
>>> standard those operations mean different things.  In the first case you
>>> get a column filled with the default value, in the second case you get a
>>> column filled with nulls.  And the latter case is the only one that
>>> works properly with a rowtype.
>
>> That's an untenable interpretation.
>
> No, *your* interpretation is untenable.  The sequence of operations that
> the previous coding allowed behaves the same for both the table and
> rowtype instances.  The "shortcut" doesn't behave the same.

By that logic, the following sequence out to be disallowed also:

rhaas=# create table foo (a int default 1);
CREATE TABLE
rhaas=# create table bar (b foo);
CREATE TABLE
rhaas=# insert into bar values (default);
INSERT 0 1
rhaas=# alter table foo alter column a set not null;
ALTER TABLE

> This was, I believe, discussed at length when the previous coding was
> put in.  The fact that you and Noah haven't read the spec carefully
> doesn't give you license to change it.

It's certainly not obvious from the archives from around 2004-06-06
that this was discussed.  Perhaps you could be a bit more specific.
As for the spec, if it requires composite types to have defaults (or
constraints), then we're in violation of that all over the place
anyway.

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

In response to

Responses

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2011-01-26 16:37:12
Subject: Re: Caution when removing git branches
Previous:From: Martijn van OosterhoutDate: 2011-01-26 16:32:35
Subject: Re: Caution when removing git branches

pgsql-committers by date

Next:From: Tom LaneDate: 2011-01-26 16:47:39
Subject: Re: [COMMITTERS] pgsql: Remove arbitrary ALTER TABLE .. ADD COLUMN restriction.
Previous:From: Tom LaneDate: 2011-01-26 16:05:32
Subject: Re: [COMMITTERS] pgsql: Remove arbitrary ALTER TABLE .. ADD COLUMN restriction.

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