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

From Tom Lane
Subject Re: BUG #6489: Alter table with composite type/table
Date
Msg-id 3220.1346172855@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #6489: Alter table with composite type/table  (Bruce Momjian <bruce@momjian.us>)
Responses Re: BUG #6489: Alter table with composite type/table
List pgsql-bugs
Bruce Momjian <bruce@momjian.us> writes:
> 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

>> TODO: alter table-type columns according to attribute type rules.
>> Enforce only TYPE features and ignore TABLE features when altering composite table-types.

> Should we add this TODO?  I am confused by the text above though.

I think this is making an assumption that we have consensus on what
are "type" properties and what are only "table" properties; that is,
is it a feature or a bug that column defaults don't work for instances
of composite types?

The ALTER code is rejecting the case on the assumption that we think
this is a bug that should get fixed eventually.  I'd only want to relax
the check if we have consensus that that will never happen.

The thread linked to via nabble above covers a lot of the background and
issues here.  It didn't seem to me that there was clear consensus.

In any case, if we do do this, ISTM the TODO is much less about removing
one test in ALTER TABLE and much more about documenting the chosen
behavior.  I think the reason you're confused by the proposed TODO
wording is exactly that it uses the phrases "TYPE features" and "TABLE
features" as if those concepts were defined or documented anywhere.

            regards, tom lane

pgsql-bugs by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: BUG #6489: Alter table with composite type/table
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] BUG #6572: The example of SPI_execute is bogus