Re: DROP COLUMN Progress - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: DROP COLUMN Progress
Date
Msg-id 200207081836.g68Ia4D13610@candle.pha.pa.us
Whole thread Raw
In response to Re: DROP COLUMN Progress  ("Christopher Kings-Lynne" <chriskl@familyhealth.com.au>)
List pgsql-hackers
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
 




pgsql-hackers by date:

Previous
From: Jan Wieck
Date:
Subject: Re: (A) native Windows port
Next
From: Tom Lane
Date:
Subject: Re: Scope of constraint names