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.

Did we find a solution for this yet?

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!

Tue, 2 Mar 1999 20:11:06 +0100
Michael Meskes <Michael_Meskes@topmail.de>
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

Wed, 03 Mar 1999 10:14:48 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] 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.

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



Wed, 3 Mar 1999 16:44:18 +0100 (MET)
jwieck@debis.com (Jan Wieck)
Re: [HACKERS] palloc.h again
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

Wed, 03 Mar 1999 18:31:52 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] palloc.h again 
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
->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<



Wed, 3 Mar 1999 18:24:59 -0600 (CST)
James Thompson <jamest@math.ksu.edu>
Re: [HACKERS] palloc.h again 
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
->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<



Sun, 7 Mar 1999 10:34:12 -0600 (CST)
James Thompson <jamest@math.ksu.edu>
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 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

Sun, 07 Mar 1999 14:22:28 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] palloc.h again 
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
->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<




Sun, 7 Mar 1999 13:47:43 -0600 (CST)
James Thompson <jamest@math.ksu.edu>
Re: [HACKERS] palloc.h again 
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!

Mon, 8 Mar 1999 08:42:56 +0100
Michael Meskes <meskes@postgresql.org>
Re: [HACKERS] palloc.h again
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

Mon, 08 Mar 1999 09:39:05 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] palloc.h again 
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!

Mon, 8 Mar 1999 20:30:32 +0100
Michael Meskes <meskes@postgreSQL.org>
Re: [HACKERS] palloc.h again