Re: BUG #6489: Alter table with composite type/table

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Rikard Pavelic <rikard(dot)pavelic(at)zg(dot)htnet(dot)hr>
Cc: Merlin Moncure <mmoncure(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #6489: Alter table with composite type/table
Date: 2012-08-28 02:40:53
Message-ID: 20120828024053.GH6786@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

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.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Chris Travers 2012-08-28 06:46:13 Re: Minor inheritance/check bug: Inconsistent behavior
Previous Message Tom Lane 2012-08-28 01:34:48 Re: [PATCH] Prevent hanging on unreachable hosts on startup