From: | Rikard Pavelic <rikard(dot)pavelic(at)zg(dot)htnet(dot)hr> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #6489: Alter table with composite type/table |
Date: | 2012-03-14 18:19:14 |
Message-ID: | 4F60E122.3080409@zg.htnet.hr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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.
Regards,
Rikard
From | Date | Subject | |
---|---|---|---|
Next Message | stuart | 2012-03-15 13:13:29 | BUG #6532: pg_upgrade fails on Python stored procedures |
Previous Message | Tom Lane | 2012-03-14 16:20:58 | Re: BUG #6531: integrity constraint failure |