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
|
Список | 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 по дате отправления: