Tom Lane wrote:
Zdenek Kotala <[EMAIL PROTECTED]> writes:
My idea is to put functions declaration int pg_xxx.h and structure
declaration in pg_xxx_def.h. I'm not sure if split DATA into separate
header is good idea, but if yes then pg_xxx_data.h should be good name
for it (it seems that pg_dump
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> My idea is to put functions declaration int pg_xxx.h and structure
> declaration in pg_xxx_def.h. I'm not sure if split DATA into separate
> header is good idea, but if yes then pg_xxx_data.h should be good name
> for it (it seems that pg_dump needs only
Tom Lane wrote:
Zdenek Kotala <[EMAIL PROTECTED]> writes:
One solution should be put sugar words into separate header and include
them directly from catalog/*.h files.
Yeah, that would probably be a good idea. It's unlikely that we'll
get away anytime soon from frontend code wanting to includ
On Sat, Oct 27, 2007 at 11:04:19AM -0400, Tom Lane wrote:
> Well, that's surely a good idea, but there'll have to be some
> negotiation to figure out how to do that. None of those files are
> currently designed with any thought of being compilable outside the
> backend environment.
>
> The hard p
Michael Meskes <[EMAIL PROTECTED]> writes:
> On Thu, Oct 25, 2007 at 11:31:15AM -0400, Tom Lane wrote:
>> ecpg cannot do that. It would fail if parser.c happened to use anything
>> that won't compile in frontend, eg elog() or palloc(). It's mere luck
>> that it's worked for him so far.
> No, act
On Thu, Oct 25, 2007 at 11:31:15AM -0400, Tom Lane wrote:
> > The problem is that ecpg shares parser.c source code and this code
> > includes postgres.h.
>
> ecpg cannot do that. It would fail if parser.c happened to use anything
> that won't compile in frontend, eg elog() or palloc(). It's mer
Zdenek Kotala wrote:
> Zdenek Kotala wrote:
> > Tom Lane wrote:
> >> Zdenek Kotala <[EMAIL PROTECTED]> writes:
>
> >>> By my opinion Datum should be defined in separate file and all
> >>> headers which use this type should include it. (this is problem on
> >>> many places with another types). An
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> One solution should be put sugar words into separate header and include
> them directly from catalog/*.h files.
Yeah, that would probably be a good idea. It's unlikely that we'll
get away anytime soon from frontend code wanting to include
catalog/pg_ty
Tom Lane wrote:
Zdenek Kotala <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Why in the world is ecpg including either primnodes.h or postgres.h?
The problem is that ecpg shares parser.c source code and this code
includes postgres.h.
ecpg cannot do that. It would fail if parser.c happened to
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Why in the world is ecpg including either primnodes.h or postgres.h?
> The problem is that ecpg shares parser.c source code and this code
> includes postgres.h.
ecpg cannot do that. It would fail if parser.c happened to use anything
Zdenek Kotala wrote:
Tom Lane wrote:
Zdenek Kotala <[EMAIL PROTECTED]> writes:
By my opinion Datum should be defined in separate file and all
headers which use this type should include it. (this is problem on
many places with another types). Another question is why ecpg needs it?
Datum is
Tom Lane wrote:
Zdenek Kotala <[EMAIL PROTECTED]> writes:
I fixed it for zic, but problem with ecpg is that it includes
nodes/primnodes.h and it requires Datum type definition which is defined
in postgres.h. :(
Why in the world is ecpg including either primnodes.h or postgres.h?
The problem
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> I fixed it for zic, but problem with ecpg is that it includes
> nodes/primnodes.h and it requires Datum type definition which is defined
> in postgres.h. :(
Why in the world is ecpg including either primnodes.h or postgres.h?
> By my opinion Datum sho
Peter Eisentraut wrote:
Am Donnerstag, 25. Oktober 2007 schrieb Zdenek Kotala:
I fixed it for zic, but problem with ecpg is that it includes
nodes/primnodes.h and it requires Datum type definition which is defined
in postgres.h. :(
I don't find an inclusion of primnodes.h in ecpg. Which file
Am Donnerstag, 25. Oktober 2007 schrieb Zdenek Kotala:
> I fixed it for zic, but problem with ecpg is that it includes
> nodes/primnodes.h and it requires Datum type definition which is defined
> in postgres.h. :(
I don't find an inclusion of primnodes.h in ecpg. Which file are you looking
at?
I'm trying to solve one TODO item mentioned in
src/backend/utils/mmgr/mcxt.c.
/*
* MemoryContextSwitchTo
* Returns the current context; installs the given context.
*
* This is inlined when using GCC.
*
* TODO: investigate supporting inlining for some non-GCC compilers.
*
16 matches
Mail list logo