Re: BETWEEN Node & DROP COLUMN

Tom Lane wrote:
> Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)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.

It may turn out to be a choice of client-cleanliness vs. backend
cleanliness. Seems Hiroshi already wins for client cleanliness. We
just need to know how many extra places need to be checked in the
backend.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026