Re: DROP COLUMN Progress
От | Christopher Kings-Lynne |
---|---|
Тема | Re: DROP COLUMN Progress |
Дата | |
Msg-id | GNELIHDDFBOCMGBFGEFOGEADCDAA.chriskl@familyhealth.com.au обсуждение исходный текст |
Ответ на | Re: DROP COLUMN Progress ("Christopher Kings-Lynne" <chriskl@familyhealth.com.au>) |
Ответы |
Re: DROP COLUMN Progress
|
Список | 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 по дате отправления: