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

Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, Bernd Helmle <mailings(at)oopsware(dot)de>, pgsql-hackers(at)postgresql(dot)org, Thom Brown <thombrown(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Subject: Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns
Date: 2010-02-02 14:50:53
Message-ID: 603c8f071002020650l6c13ab9agccecaf87ec2ab1c6@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
2010/2/1 KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>:
>> I'm making a general statement - if something is BROKEN (like the
>> rename case we just dealt with), we should look at fixing it.  If it's
>> just something that could be cleaned up or done more nicely, we should
>> leave it alone for now.
>
> OK, Please forget the second patch.
>
> The former patch (pgsql-fix-inherit-attype.1.patch) just fixes the matter
> in ALTER COLUMN TYPE case. Do you think it is a reasonable change for
> the 9.0 release?

After reviewing this, I see that it doesn't really make sense to fix
ALTER COLUMN TYPE without rewriting ADD COLUMN to use
ATSimpleRecursion().  If we're going to go to the trouble of
refactoring the ATPrepCmd() interface, we certainly want to get as
much benefit out of that as we can.

That having been said... I'm leery about undertaking a substantial
refactoring of this code at this point in the release cycle.  We have
less than two weeks remaining before the end of the final CommitFest,
so it doesn't seem like a good time to be starting new projects,
especially because we still have 16 patches that need we need to grind
through in less than 2 weeks, and I want to give some of those my
attention, too.  So I would like to push this out to 9.1 and revisit
it when I can give it the amount of time that I believe is needed to
do it right.

...Robert

In response to

Responses

pgsql-hackers by date

Next:From: Kevin GrittnerDate: 2010-02-02 15:53:08
Subject: Re: Make TOAST_TUPLES_PER_PAGE configurable per table.
Previous:From: Boszormenyi ZoltanDate: 2010-02-02 14:34:24
Subject: Re: NaN/Inf fix for ECPG Re: out-of-scope cursor errors

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