On Wed, Jan 26, 2011 at 11:05 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Wed, Jan 26, 2011 at 10:36 AM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
