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 pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026