On Mon, May 6, 2019 at 1:39 PM Ashwin Agrawal <aagra...@pivotal.io> wrote: > > Also wish to point out, while working on Zedstore, we realized that > TupleDesc from Relation object can be trusted at AM layer for > scan_begin() API. As for ALTER TABLE rewrite case (ATRewriteTables()), > catalog is updated first and hence the relation object passed to AM > layer reflects new TupleDesc. For heapam its fine as it doesn't use > the TupleDesc today during scans in AM layer for scan_getnextslot(). > Only TupleDesc which can trusted and matches the on-disk layout of the > tuple for scans hence is from TupleTableSlot. Which is little > unfortunate as TupleTableSlot is only available in scan_getnextslot(), > and not in scan_begin(). Means if AM wishes to do some initialization > based on TupleDesc for scans can't be done in scan_begin() and forced > to delay till has access to TupleTableSlot. We should at least add > comment for scan_begin() to strongly clarify not to trust Relation > object TupleDesc. Or maybe other alternative would be have separate > API for rewrite case.
Just to correct my typo, I wish to say, TupleDesc from Relation object can't be trusted at AM layer for scan_begin() API. Andres, any thoughts on above. I see you had proposed "change the table_beginscan* API so it provides a slot" in [1], but seems received no response/comments that time. [1] https://www.postgresql.org/message-id/20181211021340.mqaown4njtcgrjvr%40alap3.anarazel.de
