On Tue, 23 Dec 2025 at 06:18, Melanie Plageman <[email protected]> wrote: > > Right, it is totally okay to change function APIs in a major release. > My point was not that it wasn't allowed but that if people are getting > useful information returned from that function, or if we think we > might want that information again in the future, we should think twice > before changing it. But, in this case, I think we don't need to worry > about it. > > - Melanie
At first glance this change looks sane, and I do not find any reason why table_scan_analyze_next_tuple needs knowledge about OldestXid. But I am not aware of this function design discussions, maybe OldestXid is here for a good reason. After thinking about it for a week or so, I would actually suggest moving forward with v31 (Remove OldestXmin from TAM). I think this is a low probability of getting complaints about that. Also, we're breaking ABI, so we will know about any important use-case not long after 19-beta1. Another user of extensible TAM, Cloudberry [0], does not use OldestXmin also. I also did not find any user of scan_analyze_next_tuple other than postgresql itself with http://codesearch.decbian.net/ . Using code-search on github I found [1]. Looks like this does not need OldestXmin either. [0] https://github.com/apache/cloudberry [1] https://github.com/hydradatabase/columnar/blob/main/columnar/src/backend/columnar/columnar_tableam.c#L2080C68-L2080C78 -- Best regards, Kirill Reshke
