Re: DROP COLUMN

Поиск
Список
Период
Сортировка
От Hiroshi Inoue
Тема Re: DROP COLUMN
Дата
Msg-id 3D34F564.1108F12F@tpf.co.jp
обсуждение исходный текст
Ответ на Re: DROP COLUMN  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: DROP COLUMN  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom Lane wrote:
> 
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> >> What I asked you is what *harder to fix* means.
> 
> > Uh, some said that having attno's like 1,2,3,5,7,8,9 with gaps would
> > cause coding problems in client applications, and that was easier to
> > have the numbers as 1-9 and check a flag if the column is dropped.  Why
> > that is easier than having gaps, I don't understand.  I voted for the
> > gaps (with negative attno's) but client coders liked the flag, so we
> > went with that.
> 
> It seems to me that the problems Chris is noticing have to do with
> gaps in the sequence of valid (positive) attnums.  I don't believe that
> the negative-attnum approach to marking deleted columns would make those
> issues any easier (or harder) to fix.  Either way you have a gap.

Have I ever mentioned that negative attno's is better
than the attisdropped flag implemetation in the handling
of gaps in attnums ? And I don't object to the attisdropped
flag implemetation as long as it doesn't scatter the 
attisdropped test around client applications.
Why would you like to do nothing for clients ?

regards,
Hiroshi Inouehttp://w2422.nsk.ne.jp/~inoue/


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

Предыдущее
От: "J. R. Nield"
Дата:
Сообщение: Re: Issues Outstanding for Point In Time Recovery (PITR)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: DROP COLUMN