Re: DROP COLUMN Progress

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: DROP COLUMN Progress
Дата
Msg-id 17284.1026138392@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: DROP COLUMN Progress  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: DROP COLUMN Progress  ("Christopher Kings-Lynne" <chriskl@familyhealth.com.au>)
Список pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Christopher Kings-Lynne wrote:
>> I'm thinking that I should put a 'SearchSysCacheCopy' where my @@ comment is
>> to retrieve the attribute by name, and then do a check to see if it's
>> dropped.  Is that the best/fastest way of doing things?  Seems unfortunate
>> to add a another cache lookup in every parsed query...

> I am still looking but perhaps you could supress dropped columns from
> getting into eref in the first place.

That was my first thought also, but then the wrong attnum would be used
in the "make_var".  Ugh.  I think what Chris needs to do is extend the
eref data structure so that there can be placeholders for dropped
attributes.  Perhaps NULLs could be included in the list, and then the
code would become like
attnum++;if (lfirst(c) && strcmp(strVal(lfirst(c)), colname) == 0)    ...

This would require changes in quite a number of places :-( but I'm not
sure we have much choice.  The eref structure really needs to line up
with attnums.

Another possibility is to enter the dropped attnames in the eref list
normally, and do the drop test *after* hitting a match not before.
This is still slow, but not as horrendously O(N^2) slow as Chris's
original pseudocode.  I'm not sure how much work it'd really save though;
you might find yourself hitting all the same places to add tests.
        regards, tom lane




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Proposal: CREATE CONVERSION
Следующее
От: Thomas Lockhart
Дата:
Сообщение: Re: Proposal: CREATE CONVERSION