Re: BETWEEN Node & DROP COLUMN

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BETWEEN Node & DROP COLUMN
Дата
Msg-id 191.1025759090@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BETWEEN Node & DROP COLUMN  (Hiroshi Inoue <Inoue@tpf.co.jp>)
Ответы Re: BETWEEN Node & DROP COLUMN  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-hackers
Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> I used the following macro in my trial implementation.
>  #define COLUMN_IS_DROPPED(attribute) ((attribute)->attnum <= 
> DROP_COLUMN_OFFSET)
> The places where the macro was put are exactly the places
> where attisdropped must be checked.

Actually, your trial required column dropped-ness to be checked in
many more places than the proposed approach does.  Since you renumbered
the dropped column, nominal column numbers didn't correspond to physical
order of values in tuples anymore; that meant checking for dropped
columns in many low-level tuple manipulations.

>> Is this correct?  I certainly prefer attno renumbering to isdropped
>> because it allows us to get DROP COLUMN without any client changes,

> Unfortunately many apps rely on the fact that the attnos are
> consecutive starting from 1. It was the main reason why Tom
> rejected my trial. Nothing has changed about it.

I'm still not thrilled about it ... but I don't see a reasonable way
around it, either.  I don't see any good way to do DROP COLUMN
without breaking applications that make such assumptions.  Unless
you have one, we may as well go for the approach that adds the least
complication to the backend.
        regards, tom lane




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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Adding attisdropped
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: BETWEEN Node & DROP COLUMN