Andres Freund <and...@anarazel.de> writes: > On 2022-12-07 17:32:21 -0500, Tom Lane wrote: >> +typedef struct Node *NodePtr;
> Seems like it'd be easier to just forward declare the struct, and use the > non-typedef'ed name in the header than to have to deal with these > interdependencies and the differing typenames. I've been having second thoughts about how to handle this issue. As we convert more and more datatypes, references to "Node *" are going to be needed in assorted headers that don't currently have any reason to #include nodes.h. Rather than bloating their include footprints, we'll want to use the alternate spelling, whichever it is. (I already had to do this in array.h.) Some of these headers might be things that are also read by frontend compiles, in which case they won't have access to elog.h either, so that NodePtr in this formulation won't work for them. (I ran into a variant of that with an early draft of this patch series.) If we stick with NodePtr we'll probably end by putting that typedef into c.h so that it's accessible in frontend as well as backend. I don't have a huge problem with that, but I concede it's a little ugly. If we go with "struct Node *" then we can solve such problems by just repeating "struct Node;" forward-declarations in as many headers as we have to. This is a bit ugly too, but maybe less so, and it's a method we use elsewhere. The main downside I can see to it is that we will probably not find out all the places where we need such declarations until we get field complaints that "header X doesn't compile for me". elog.h will have a struct Node declaration, and that will be visible in every backend compilation we do as well as every cpluspluscheck/headerscheck test. Another notational point I'm wondering about is whether we want to create hundreds of direct references to fcinfo->context. Is it time to invent #define PG_GET_CONTEXT() (fcinfo->context) and write that instead in all these input functions? Thoughts? regards, tom lane