Thread: Re: [BUGS] ALTER TABLE table RENAME COLUMN x TO y

Re: [BUGS] ALTER TABLE table RENAME COLUMN x TO y

From
Tom Lane
Date:
"Donald Fraser" <demolish@cwgsy.net> writes:
> When issuing the following type of command:
> ALTER TABLE table RENAME COLUMN x TO y
> The column name change is not cascading through to RULEs on a VIEW.

More specifically, INSERTs and UPDATEs contained in rules don't have
their target column names adjusted.  This is because the "resname"
fields in their targetlists contain the original column names, and
those fields are actually looked at to determine the target columns.

I think this behavior is vestigial, and we could both simplify the code
and make it RENAME-proof by using just the "resno" fields to determine
the target columns.  "resname" would then have just one purpose: to
carry the "AS" alias of targetlist entries in SELECTs.  There is already
code in ruleutils.c to allow "resname" to be overridden by the current
column name of a view (thus handling RENAME applied to the view itself),
and I don't think "resname" is user-visible in any other way.

Anyone see a problem with this plan?

I regard this as something we should fix for 7.4, mainly because if you
use --enable-cassert then the backend actually dumps core when trying to
execute the outdated rule (there are Asserts in there that notice the
resname mismatch).
        regards, tom lane


Re: [BUGS] ALTER TABLE table RENAME COLUMN x TO y

From
Bruce Momjian
Date:
Tom Lane wrote:
> "Donald Fraser" <demolish@cwgsy.net> writes:
> > When issuing the following type of command:
> > ALTER TABLE table RENAME COLUMN x TO y
> > The column name change is not cascading through to RULEs on a VIEW.
> 
> More specifically, INSERTs and UPDATEs contained in rules don't have
> their target column names adjusted.  This is because the "resname"
> fields in their targetlists contain the original column names, and
> those fields are actually looked at to determine the target columns.
> 
> I think this behavior is vestigial, and we could both simplify the code
> and make it RENAME-proof by using just the "resno" fields to determine
> the target columns.  "resname" would then have just one purpose: to
> carry the "AS" alias of targetlist entries in SELECTs.  There is already
> code in ruleutils.c to allow "resname" to be overridden by the current
> column name of a view (thus handling RENAME applied to the view itself),
> and I don't think "resname" is user-visible in any other way.
> 
> Anyone see a problem with this plan?
> 
> I regard this as something we should fix for 7.4, mainly because if you

Oh, man, you are reaching with that one, but I like it.  :-)

> use --enable-cassert then the backend actually dumps core when trying to
> execute the outdated rule (there are Asserts in there that notice the
> resname mismatch).

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073