On Wed, Mar 7, 2012 at 2:31 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Merlin Moncure <mmoncure@gmail.com> writes:
>> On Wed, Mar 7, 2012 at 11:45 AM, Mike Blackwell <mike.blackwell@rrd.com> 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
