Bruce Momjian wrote:
>
> Hiroshi Inoue wrote:
> > Bruce Momjian wrote:
> > >
> > > Hiroshi Inoue wrote:
> > > > > As I remember, Hiroshi's drop column changed the attribute number to a
> > > > > special negative value, which required lots of changes to track.
> > > >
> > > > ??? What do you mean by *lots of* ?
> > >
> > > Yes, please remind me. Was your solution renumbering the attno values?
> >
> > Yes though I don't intend to object to Christopher's proposal.
> >
> > > I think there are fewer cases to fix if we keep the existing attribute
> > > numbering and just mark the column as deleted. Is this accurate?
> >
> > No. I don't understand why you think so.
>
> With the isdropped column, you really only need to deal with '*'
> expansion in a few places, and prevent the column from being accessed.
> With renumbering, the backend loops that go through the attnos have to
> be dealt with.
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.
The difference is essentially little. Please don't propagate
a wrong information.
> 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.
regards,
Hiroshi Inouehttp://w2422.nsk.ne.jp/~inoue/
