palloc.h again

Michael Meskes <Michael_Meskes@topmail.de> writes:

I just noticed that the palloc.h problem still exists. That is we do not
install utils/mcxt.h but is included by palloc.h.

I was hoping that Jan would try to reduce the number of include files
that are now needed by palloc(). But definitely something will have
to be done about this before we release.

regards, tom lane

Michael Meskes <Michael_Meskes@topmail.de> writes:

I just noticed that the palloc.h problem still exists. That is we do not
install utils/mcxt.h but is included by palloc.h.

I was hoping that Jan would try to reduce the number of include files
that are now needed by palloc(). But definitely something will have
to be done about this before we release.

Hmmm - how should I reduce the number of include files? All
the palloc stuff is macroized now, so using palloc() results
in MemoryContextAlloc() calls. Reduces one brain dead
function call (the old versions of palloc() etc. simply did
that - wasting one stack frame).

Thus, we definitely need mcxt.h where we need palloc() and
that's why I've put the include of mcxt.h into palloc.h.

What I'm in doubt about is, why (if) we don't want to install
mcxt.h? It is required (since my changes) by every user
built backend-loadable module. So it should be installed.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #

jwieck@debis.com (Jan Wieck) writes:

What I'm in doubt about is, why (if) we don't want to install
mcxt.h? It is required (since my changes) by every user
built backend-loadable module. So it should be installed.

If it's only mcxt.h that is newly required, we may as well just export
it and be done with it. My recollection of the original report was
that *several* formerly backend-private headers needed to be added to
the export set, and I thought that wasn't a very good idea...

regards, tom lane

On Wed, 3 Mar 1999, Tom Lane wrote:

jwieck@debis.com (Jan Wieck) writes:

What I'm in doubt about is, why (if) we don't want to install
mcxt.h? It is required (since my changes) by every user
built backend-loadable module. So it should be installed.

If it's only mcxt.h that is newly required, we may as well just export
it and be done with it. My recollection of the original report was
that *several* formerly backend-private headers needed to be added to
the export set, and I thought that wasn't a very good idea...

It's been a while since I switched to CVS but I remember other .h
dependencies with each .h file I added starting with palloc.h. I ended up
getting tired of it and just copied the contents of the include dir over
rather than fight with it. So unless somethings changed there are more
headers needed that palloc.h and mcxt.h Sorry I don't have better
details as to which ones it needed. I'll be doing a fresh install this
weekend, if it'd help I'll make a list.

->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<
James Thompson 138 Cardwell Hall Manhattan, Ks 66506 785-532-0561
Kansas State University Department of Mathematics
->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<

On Tue, 2 Mar 1999, Michael Meskes wrote:

I just noticed that the palloc.h problem still exists. That is we do not
install utils/mcxt.h but is included by palloc.h.

After doing a clean install of todays CVS, I tried to compile one of the
ecpg based programs. These are the dependencies that failed as a copied
the needed files into place.

[jamest@calvin obelib]$ make
make: *** No rule to make target `/usr/local/pgsql/include/utils/mcxt.h',
needed by `packet.lo'. Stop.
[jamest@calvin obelib]$ make
make: *** No rule to make target
`/usr/local/pgsql/include/nodes/memnodes.h', needed by `packet.lo'. Stop.
[jamest@calvin obelib]$ make
make: *** No rule to make target `/usr/local/pgsql/include/lib/fstack.h',
needed by `packet.lo'. Stop.
[jamest@calvin obelib]$ make
make: *** No rule to make target
`/usr/local/pgsql/include/utils/memutils.h', needed by `packet.lo'. Stop.
[jamest@calvin obelib]$ make
make: *** No rule to make target `/usr/local/pgsql/include/nodes/nodes.h',
needed by `packet.lo'. Stop.

->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<
James Thompson 138 Cardwell Hall Manhattan, Ks 66506 785-532-0561
Kansas State University Department of Mathematics
->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<

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 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

On Sun, 7 Mar 1999, Tom Lane wrote:

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

I should have left the ecpg part out as I don't think it was important.
All my code requires ecpg and it was easy to just build what I'm familure
with and submit the results. I didn't try a libpg based program.

->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<
James Thompson 138 Cardwell Hall Manhattan, Ks 66506 785-532-0561
Kansas State University Department of Mathematics
->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<

On Sun, Mar 07, 1999 at 02:22:28PM -0500, Tom Lane wrote:

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.

Hmm, historically ecpg's ecpglib.h includes postgres.h which include
palloc.h. But scanning through postgres.h I wonder why.

I will check that as soon as I find time.

Michael
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael.Meskes@gmx.net | Use PostgreSQL!

Michael Meskes <meskes@postgreSQL.org> writes:

On Sun, Mar 07, 1999 at 02:22:28PM -0500, Tom Lane wrote:

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.

Hmm, historically ecpg's ecpglib.h includes postgres.h which include
palloc.h. But scanning through postgres.h I wonder why.

It'd probably be better if you could make ecpg code depend only on
postgres_ext.h. However, I did commit fixes yesterday to solve the
immediate problem with mcxt.h.

regards, tom lane

On Mon, Mar 08, 1999 at 09:39:05AM -0500, Tom Lane wrote:

It'd probably be better if you could make ecpg code depend only on
postgres_ext.h. However, I did commit fixes yesterday to solve the
immediate problem with mcxt.h.

I found I essantially need only c.h (and config.h of course). I will change
my include file to just include these.

Michael
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael.Meskes@gmx.net | Use PostgreSQL!