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

From Merlin Moncure
Subject Re: BUG #6489: Alter table with composite type/table
Date
Msg-id CAHyXU0wtwFqRJb8UE0OETEb9-Bvr09Gok0W9XadcPU5PisgAuQ@mail.gmail.com
Whole thread Raw
In response to Re: BUG #6489: Alter table with composite type/table  (Bruce Momjian <bruce@momjian.us>)
List pgsql-bugs
On Mon, Aug 27, 2012 at 9:40 PM, Bruce Momjian <bruce@momjian.us> wrote:
> On Wed, Mar 14, 2012 at 07:19:14PM +0100, Rikard Pavelic wrote:
>> On 13.3.2012. 20:49, Merlin Moncure wrote:
>> > I personally think it's an oversight.  This was just discussed a
>> > couple of days ago here:
>> > http://postgresql.1045698.n5.nabble.com/Altering-a-table-with-a-rowtype-column-td5544844.html
>> >
>> > The server is blocking the alter-not-null-with-default because it's
>> > assuming that the default should be applied to dependent (foreign)
>> > tables implementing the type as a field.  I think this assumption is
>> > totally bogus because composite types defaults get applied to the
>> > type, not to member fields and therefore a default has no meaning in
>> > that context.   I think the TODO should read to relax the check
>> > essentially.
>> >
>> > merlin
>> >
>>
>> I agree.
>> TODO: alter table-type columns according to attribute type rules.
>> Enforce only TYPE features and ignore TABLE features when altering composite table-types.
>>
>> While I'm making up TODO's, my favorite one: support recursive types.
>
> Should we add this TODO?  I am confused by the text above though.

I think so, but you should read the referenced thread for some
background -- especially Tom's comments.  What's missing is a
consensus on how defaults and tables-as-rowtypes interact; and before
working on a TODO that should be established.

merlin

pgsql-bugs by date:

Previous
From: Ryan Kelly
Date:
Subject: Re: [PATCH] Prevent hanging on unreachable hosts on startup
Next
From: Tom Lane
Date:
Subject: Re: BUG #6489: Alter table with composite type/table