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
