Re: BETWEEN Node & DROP COLUMN

Tom Lane wrote:
> Hiroshi Inoue <Inoue@tpf.co.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@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026