Re: DROP COLUMN Progress - Mailing list pgsql-hackers

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

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...

Chris






pgsql-hackers by date:

Previous
From: "Christopher Kings-Lynne"
Date:
Subject: Re: DROP COLUMN Progress
Next
From: Tatsuo Ishii
Date:
Subject: Re: Proposal: CREATE CONVERSION