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

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Donald Fraser <demolish(at)cwgsy(dot)net>, pgsql-bugs(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] ALTER TABLE table RENAME COLUMN x TO y
Date: 2003-08-11 22:22:14
Message-ID: 200308112222.h7BMMEF06765@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

Tom Lane wrote:
> "Donald Fraser" <demolish(at)cwgsy(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Kevin Houle 2003-08-12 15:10:10 UNIQUE INDEX difference between 7.2 and 7.3
Previous Message Mike Nerone 2003-08-11 19:46:01 SysV startup script name in binary RPM distribution

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2003-08-11 22:23:47 Re: Change Request: \pset pager off in pg_dumpall
Previous Message Bruce Momjian 2003-08-11 21:50:11 Re: Farewell