Re: [HACKERS] palloc.h again

James Thompson <jamest@math.ksu.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 puttingtypedef struct MemoryContextData *MemoryContext;typedef
structGlobalMemoryData *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