On Tue, Jan 10, 2023 at 3:48 AM Peter Eisentraut <peter.eisentr...@enterprisedb.com> wrote: > >>> Wow, 41 files requiring varatt.h is a lot fewer than I would have guessed. > >>> I think that bears out my feeling that fmgr.h wasn't a great location: > >>> I count 117 #includes of that, many of which are in .h files themselves > >>> so that many more .c files would be required to read them. > >> > >> committed > > > > SET_VARSIZE alone appears in 74 pgxn distributions, so I predict extension > > breakage en masse. I would revert this. > > Well, that was sort of my thinking, but people seemed to like this. I'm > happy to consider alternatives.
I don't think that the number of extensions that get broken is really the right metric. It's not fantastic to break large numbers of extensions, of course, but if the solution is merely to add an #if PG_VERSION_NUM >= whatever #include "newstuff" #endif then I don't think it's really an issue. If an extension doesn't have an author who can do at least that much updating when a new PG release comes out, then it's basically unmaintained, and I just don't feel that bad about breaking unmaintained extensions now and then, even annually. Of course, if we go and remove something that's very widely used and for which there's no simple workaround, that sucks. Say, removing LWLocks entirely. But we don't usually do that sort of thing unless there's a good reason and significant benefits. I don't think it would be very nice to do something like this in a minor release. But in a new major release, I think it's fine. I've been on the hook to maintain extensions in the face of these kinds of changes at various times over the years, and it's never taken me much time. -- Robert Haas EDB: http://www.enterprisedb.com