Re: BETWEEN Node & DROP COLUMN - Mailing list pgsql-hackers

From Tom Lane
Subject Re: BETWEEN Node & DROP COLUMN
Date
Msg-id 191.1025759090@sss.pgh.pa.us
Whole thread Raw
In response to Re: BETWEEN Node & DROP COLUMN  (Hiroshi Inoue <Inoue@tpf.co.jp>)
Responses Re: BETWEEN Node & DROP COLUMN
List pgsql-hackers
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.
        regards, tom lane




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Adding attisdropped
Next
From: Bruce Momjian
Date:
Subject: Re: BETWEEN Node & DROP COLUMN