Re: [HACKERS] Datum should be defined outside postgres.h

2007-10-30 Thread Zdenek Kotala
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

Re: [HACKERS] Datum should be defined outside postgres.h

2007-10-30 Thread Tom Lane
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

Re: [HACKERS] Datum should be defined outside postgres.h

2007-10-30 Thread Zdenek Kotala
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

Re: [HACKERS] Datum should be defined outside postgres.h

2007-10-27 Thread Michael Meskes
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

Re: [HACKERS] Datum should be defined outside postgres.h

2007-10-27 Thread Tom Lane
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

Re: [HACKERS] Datum should be defined outside postgres.h

2007-10-27 Thread Michael Meskes
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

Re: [HACKERS] Datum should be defined outside postgres.h

2007-10-25 Thread Bruce Momjian
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

Re: [HACKERS] Datum should be defined outside postgres.h

2007-10-25 Thread Tom Lane
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

Re: [HACKERS] Datum should be defined outside postgres.h

2007-10-25 Thread Zdenek Kotala
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

Re: [HACKERS] Datum should be defined outside postgres.h

2007-10-25 Thread Tom Lane
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

Re: [HACKERS] Datum should be defined outside postgres.h

2007-10-25 Thread Zdenek Kotala
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

Re: [HACKERS] Datum should be defined outside postgres.h

2007-10-25 Thread Zdenek Kotala
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

Re: [HACKERS] Datum should be defined outside postgres.h

2007-10-25 Thread Tom Lane
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

Re: [HACKERS] Datum should be defined outside postgres.h

2007-10-25 Thread Zdenek Kotala
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

Re: [HACKERS] Datum should be defined outside postgres.h

2007-10-25 Thread Peter Eisentraut
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?

[HACKERS] Datum should be defined outside postgres.h

2007-10-25 Thread Zdenek Kotala
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. *