Re: BUG #6489: Alter table with composite type/table - Mailing list pgsql-bugs

From Marti Raudsepp
Subject Re: BUG #6489: Alter table with composite type/table
Date
Msg-id CABRT9RAif=sWTUeqxjDJe6i4vpkmVVcq9Qt02XL+osPtCH=bxA@mail.gmail.com
Whole thread Raw
In response to BUG #6489: Alter table with composite type/table  (rikard.pavelic@zg.htnet.hr)
Responses Re: BUG #6489: Alter table with composite type/table
List pgsql-bugs
On Sat, Feb 25, 2012 at 15:23,  <rikard.pavelic@zg.htnet.hr> wrote:
> This works:
> alter table t1 add x float not null;
> This doesn't work:
> alter table t1 add x float not null default 0;
> It fails with ERROR: =C2=A0cannot alter table "t1" because column "t2.j" =
uses its
> row type

> But I would expect second alter to pass and enforcing not null and default
> when adding this column in table and not enforcing not null and default w=
hen
> adding into composite type for another table.
>
> Is this by design, oversight or a TODO?

Peeking at the code, currently any modifications that cause a rewrite
of the original table are disallowed.

Adding a nullable column without a default is allowed since it can be
done without a rewrite -- all rows magically get the value NULL.

I'm not sure whether it's worth complicating code for this. If you
want to store composite types in tables, I think you're better off
using CREATE TYPE/ALTER TYPE.

Regards,
Marti

pgsql-bugs by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: BUG #6495: mis-sorting on string field consisting of space-padded numbers
Next
From: r d
Date:
Subject: pgadmin3 update to 1.14.2 erases /usr/bin link