"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