On Wed, Nov 19, 2025 at 11:49 AM Álvaro Herrera <[email protected]> wrote: > > I'm rather late to the party here, but for what it's worth, I don't > > really think this was a good idea. Anyone who wants to write > > out-of-core code that works in the back-branches must still write it > > the old way, or it will potentially fail on older minor releases. > > No, they don't need to. Thus far, they can still keep their code the > way it is.
True, but if they write any new code, and care about it compiling with older minor releases, this is a potential pitfall. > The next patch in the series (not yet committed, but I > intend to get it out at some point, unless there are objections) is > going to add an obsolescence warning when their code is compiled with > Postgres 21 -- by which time the minors without the new macro are going > to be two years old. Nobody needs to compile their code with minor > releases that old. So they can fix their code to work with Postgres 21 > and with all contemporary minors. They don't need to ensure that their > code compiles with minors older than that. Well, if nobody needs to do this, then there's no problem, of course. I doubt that's true, though. > We could make that Postgres 22, but I don't think that makes any > practical difference. > > Maybe you misunderstood what the patch is doing. It's possible, but fundamentally I think it's about replacing XLogRecPtrIsInvalid with XLogRecPtrIsValid, and what I'm saying is I wouldn't have chosen to do that. I agree that it would have been better to do it that way originally, but I disagree with paying the switching cost, especially in the back-branches. -- Robert Haas EDB: http://www.enterprisedb.com
