Re: DROP COLUMN Progress

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

In response to

Responses

Browse pgsql-hackers by date

  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