Re: RFC: Restructuring pg_aggregate

Tom Lane wrote:
>
> Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)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 whether this 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.