Tom Lane wrote:
>
> Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> > Tom Lane wrote:
> >> That means that
> >> a lot of low-level places *do* need to know about the dropped-column
> >> convention, else they can't make any sense of tuple layouts.
>
> > Why ? As you already mentioned, there were not that many places
> > to be changed.
>
> There are not many places to change if the implementation uses
> attisdropped, because we *only* have to hide the existence of the column
> at the parser level. The guts of the system don't know anything funny
> is going on; a dropped column looks the same as an undropped one
> throughout the executor. But with negative attnums, even such basic
> routines as heap_formtuple have to know about it, no?
When a tuple descriptor is made, the info of
dropped columns are placed at (their physical
position - 1) index in the same way as ordinary
columns. There are few places where conversions
between negative attnums and the physical positions
are needed.
The following is my posting more than 2 years ago.
What's changed since then.
regards,
Hiroshi Inoue
I don't want a final implementation this time. What I want is to provide a quick hack for both others and me to judge
whetherthis direction is good or not.
My idea is essentially an invisible column implementation. DROP COLUMN would change the target pg_attribute tuple as
follows..attnum -> an offset - attnum;atttypid -> 0
We would be able to see where to change by tracking error/ crashes caused by this change.
I would also change attname to '*already dropped %d' for examle to avoid duplicate attname.