Re: [HACKERS] palloc.h again

James Thompson <jamest(at)math(dot)ksu(dot)edu> writes:
> After doing a clean install of todays CVS, I tried to compile one of the
> ecpg based programs.

Wait a sec ... ecpg? ecpg shouldn't be depending on backend internals
at all, should it? I thought we were talking about support for
dynamically loaded backend extensions.

> These are the dependencies that failed as a copied
> the needed files into place.
> include/utils/mcxt.h
> include/nodes/memnodes.h
> include/lib/fstack.h
> include/utils/memutils.h
> include/nodes/nodes.h

OK, thanks for the list. Now the question is do we want to expose that
much of the backend internals to dynamically loaded extensions in order
to allow palloc() to be a macro.

It looks to me like there's no real need for mcxt.h to import
memnodes.h; as far as most users of palloc are concerned, the type
MemoryContext is just an abstract token. I propose putting
typedef struct MemoryContextData *MemoryContext;
typedef struct GlobalMemoryData *GlobalMemory;
in mcxt.h instead of including memnodes.h. Then we avoid needing to
export more than mcxt.h... should speed up backend rebuilds a little bit
too, as palloc.h is included in a lot of files that don't need the rest
of that stuff...

I'll try this and see if it compiles that way.

regards, tom lane