Re: [HACKERS] palloc.h again - Mailing list pgsql-hackers

From jwieck@debis.com (Jan Wieck)
Subject Re: [HACKERS] palloc.h again
Date
Msg-id m10IDop-000EBQC@orion.SAPserv.Hamburg.dsh.de
Whole thread Raw
In response to Re: [HACKERS] palloc.h again  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] palloc.h again
List pgsql-hackers
>
> 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) #

pgsql-hackers by date:

Previous
From: "Thomas G. Lockhart"
Date:
Subject: Re: [PORTS] Port Bug Report: Error with date_part when checking month
Next
From: "Thomas G. Lockhart"
Date:
Subject: Re: [COMMITTERS] 'pgsql/src/backend/parser parse.h gram.c'