Re: RFC: Restructuring pg_aggregate

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.