Re: BUG #16909: On update (not insert) the attisdropped flag is set for tables which are recreated with the same col

Thanks Tom, that explains it.

I had seen the use of attisdropped elsewhere, thought I'd better check it
and assumed that the TupleDescAttr was 1 based, like the SPI functions,
rather than 0 based. I have now gone into the code and it does indeed have
a comment /* attrs[N] is the description of Attribute Number N+1 */

It also explains why Hamid got different results. Sorry to raise a false
alarm.

On Tue, 2 Mar 2021 at 15:40, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> > On update (not insert) the attisdropped flag is set for tables which
> are
> > recreated with the same column names as the original but where preceding
> > columns have been dropped
>
> I think this is just faulty C code.
>
> > for( int i = 1; i <= tupdesc->natts; i++ ) {
> > elog( INFO, "attr num=%d attisdropped=%d", i, TupleDescAttr(
> tupdesc, i
> > )->attisdropped );
> > }
>
> The index argument of TupleDescAttr needs to run from 0 to natts-1.
> As coded, this is fetching off the end of the array and getting garbage.
>
> The mistake might've been more obvious if you'd tried to print any
> non-boolean fields of the tupledesc.
>
> regards, tom lane
>