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
