On Wed, Jan 26, 2011 at 11:05 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Wed, Jan 26, 2011 at 10:36 AM, Tom Lane <tgl@sss.pgh.pa.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
