Christopher Kings-Lynne wrote: > > > I am still looking but perhaps you could supress dropped columns from > > > getting into eref in the first place. > > > > OK, that's done. I'm working on not allowing dropped columns in UPDATE > > targets now. > > OK, I've fixed it so that dropped columns cannot be targetted in an update > statement, however now I'm running into this problem: > > If you issue an INSERT statement without qualifying any field names, ie: > > INSERT INTO tab VALUES (3); > > Although it will automatically insert NULL for the dropped columns, it still > does cache lookups for the type of the dropped columns, etc. I noticed that > when I tried setting the atttypid of the dropped column to (Oid)-1. Where > is the bit of code that figures out the list of columns to insert into in an > unqualified INSERT statement?
parse_target.c::checkInsertTargets() > > I'm thinking that it would be nice if the dropped columns never even make it > into the list of target attributes, for performance reasons... Yea, just sloppy to have them there. -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
