Re: MaxOffsetNumber for Table AMs

On Fri, 2021-04-30 at 13:56 -0400, Robert Haas wrote:
> I think that would be the best long-term plan.

We should still have *some* answer in the short term for table AM
authors like me. If I use offset numbers as high as MaxOffsetNumber,
then itemptr_to_uint64 will fail. If I base my calculations for the TID
to row number mapping on MaxOffsetNumber at all, then it will break if
we change MaxOffsetNumber (as was suggested[1]).

My takeaway so far is that the only safe thing to do is hard code it to
2000. I suppose I can do that until we settle on something better (at
which point I can force a reindex, I suppose).

[1]
https://postgr.es/m/CAEze2Wit1EtHHBHJ+CYvBPthrWUzu2Vqc-BmzU3ApK3iotHriw@mail.gmail.com

> Even though these are distinguishable concerns, they basically point
> in the same direction as far as index layout is concerned. The
> implications for the table AM layer are somewhat different in the two
> cases, but both argue that some places that are now talking about
> TIDs
> should be changed to talk about Datums or something of that sort.

Logically, that makes a lot of sense to me. Peter seems to have quite a
few practical implementation concerns though, so it could be a long
road.

Regards,
Jeff Davis