From: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Rod Taylor <rbt(at)zort(dot)ca>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: DROP COLUMN |
Date: | 2002-07-17 04:41:08 |
Message-ID: | 3D34F564.1108F12F@tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
>
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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 Inoue
http://w2422.nsk.ne.jp/~inoue/
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2002-07-17 04:44:01 | Re: DROP COLUMN |
Previous Message | J. R. Nield | 2002-07-17 04:24:10 | Re: Issues Outstanding for Point In Time Recovery (PITR) |