On Tue, Jan 10, 2023 at 9:46 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > Now, there is a fair question whether splitting this code out of > postgres.h is worth any trouble at all. TBH my initial reaction > had been "no". But once we found that only 40-ish backend files > need to read this new header, I became a "yes" vote because it > seems clear that there will be a total-compilation-time benefit.
I wasn't totally about this, either, but I think on balance it's probably a smart thing to do. I always found it kind of weird that we put that stuff in postgres.h. It seems to privilege the TOAST mechanism to an undue degree; what's the argument, for example, that TOAST macros are more generally relevant than CHECK_FOR_INTERRUPTS() or LWLockAcquire or HeapTuple? It felt to me like we'd just decided that one subsystem gets to go into the main header file and everybody else just had to have their own headers. One thing that's particularly awkward about that is that if you want to write some front-end code that knows about how varlenas are stored on disk, it was very awkward with the old structure. You're not supposed to include "postgres.h" into frontend code, but if the stuff you need is defined there then what else can you do? So I generally think that anything that's in postgres.h should have a strong claim to be not only widely-needed in the backend, but also never needed at all in any other executable. -- Robert Haas EDB: http://www.enterprisedb.com
