On Wed, Mar 7, 2012 at 2:31 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > Merlin Moncure <mmoncure@xxxxxxxxx> writes: >> On Wed, Mar 7, 2012 at 11:45 AM, Mike Blackwell <mike.blackwell@xxxxxxx> wrote: >>> alter table a add column even_more_stuff boolean not null default false; > >> aha! that's not what you posted last time. you appended 'not null >> default false'; which inexplicably breaks the ALTER. > >> try this: >> ALTER TABLE a ADD COLUMN even_more_stuff text not null; >> ALTER TABLE a ALTER even_more_stuff set default false; >> ALTER TABLE a DROP COLUMN even_more_stuff; >> ALTER TABLE a ADD COLUMN even_more_stuff boolean not null default false; > >> (this really looks like a bug in postgres, cc-ing to bugs) > > It is not a bug. The ALTER ADD ... DEFAULT ... form implies rewriting > every existing tuple of the rowtype to insert a non-null value in the > added column, and we don't have support for doing that to rowtype > columns, only to the target table and descendants. I'm not buying that..it implies no such thing. In particular, for table-as-rowtype columns, there's no way that I can see to have default values be generated. So why does it follow that the dependent table has to be rewritten? Column constraints are not enforced on the rowtype, so it follows that default shouldn't be either considering there's no way to get the default to fire. Composite type (or table based composite) defaults are applied to the composite as a whole, not to specific fields. On a practical level, the error blocks nothing -- you can bypass it trivially. It's just an annoyance that prevents things that users would like to be able to do with table row types. So I'd argue to remove the check, although I can kinda see the argument that it's not a bug unless the check was recently introduced so that it broke older code. merlin -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
