Re: BETWEEN Node & DROP COLUMN

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.

regards, tom lane