From: | "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> |
---|---|
To: | "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au>, "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: DROP COLUMN Progress |
Date: | 2002-07-08 07:51:03 |
Message-ID: | GNELIHDDFBOCMGBFGEFOGEADCDAA.chriskl@familyhealth.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2002-07-08 08:34:28 | Re: Proposal: CREATE CONVERSION |
Previous Message | Christopher Kings-Lynne | 2002-07-08 05:09:59 | Re: DROP COLUMN Progress |