Skip site navigation (1) Skip section navigation (2)

Re: [GENERAL] Altering a table with a rowtype column

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Mike Blackwell <mike(dot)blackwell(at)rrd(dot)com>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>, PostgreSQL General <pgsql-general(at)postgresql(dot)org>
Subject: Re: [GENERAL] Altering a table with a rowtype column
Date: 2012-03-08 17:08:36
Message-ID: CAHyXU0xMfV_KHcboAGhZ5RMQ58xK3ZSek5VT7CYsAPa=1DbKOA@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-general
On Wed, Mar 7, 2012 at 2:49 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> On a practical level, the error blocks nothing -- you can bypass it
> trivially.   It's just an annoyance that prevents things that users
> would like to be able to do with table row types.  So I'd argue to
> remove the check, although I can kinda see the argument that it's not
> a bug unless the check was recently introduced so that it broke older
> code.

The behavior hasn't changed since at least as far back as 8.1, so
you're correct (once again) -- not a bug.  I'm really surprised I
haven't already bumped into this.  I usually don't mix
tables-as-storage with tables-as-composites though.

Mike, on 9.1, you'll probably get more mileage out of using the hstore
type for row storage if you want to do auditing in that style.

merlin

In response to

Responses

pgsql-bugs by date

Next:From: Tom LaneDate: 2012-03-08 17:19:21
Subject: Re: Extension tracking temp table and causing update failure
Previous:From: Dimitri FontaineDate: 2012-03-08 16:59:57
Subject: Re: Extension tracking temp table and causing update failure

pgsql-general by date

Next:From: mgouldDate: 2012-03-08 17:33:36
Subject: why no create variable
Previous:From: Guillaume LelargeDate: 2012-03-08 16:23:37
Subject: Re: How to erase transaction logs on PostgreSQL

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group