Tom Lane wrote: > "Donald Fraser" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
