Re: Suggested change in include/utils/elog.h

If you do decide to prefix DEBUG, please consider prefixing at least ERROR
as well. It produces a lot of warnings when compiling on Win32 (ERROR is
already defined as part of the standard windows headers). It's just
warnings, though.

//Magnus

Magnus Hagander wrote:

If you do decide to prefix DEBUG, please consider prefixing at least ERROR
as well. It produces a lot of warnings when compiling on Win32 (ERROR is
already defined as part of the standard windows headers). It's just
warnings, though.

//Magnus

Do other people have a comment on this. I am inclined to leave it
along. This is the first complaint I have heard, and
elog(PGDEBUG) just
looks funny. We don't prefix NOTICE or ERROR.

In the file

include/utils/elog.h

there is a macro named

DEBUG

that conflicts with the perl5.6 macro DEBUG.

PostgreSQL would probably "play" better with other products if
the DEBUG macro had a prefix, maybe PGSQLDEBUG or similar.

Until there is some fix in this area, plperl will not build with
a version of perl that has debugging enabled.

It even got on my nerves (linux, ecpg) since I used to define a macro
#define DEBUG(x) cout << x
or
#define DEBUG(x)

DEBUG and ERROR are far too common to get defined for client programs.

But perhaps it is ecpg's fault for including "elog.h".
IMHO these defines should never leave the database kernel.

perhaps the common
#ifdef _DBKERNEL_
#endif
would do the trick.

Christof

PS: Having Datum unconditionally leaked to ecpg programs forced me to preced
a namespace to my own class.

PostgreSQL would probably "play" better with other products if
the DEBUG macro had a prefix, maybe PGSQLDEBUG or similar.

Until there is some fix in this area, plperl will not build with
a version of perl that has debugging enabled.

It even got on my nerves (linux, ecpg) since I used to define a macro
#define DEBUG(x) cout << x
or
#define DEBUG(x)

DEBUG and ERROR are far too common to get defined for client programs.

But perhaps it is ecpg's fault for including "elog.h".
IMHO these defines should never leave the database kernel.

perhaps the common
#ifdef _DBKERNEL_
#endif
would do the trick.

Christof

PS: Having Datum unconditionally leaked to ecpg programs forced me to preced
a namespace to my own class.

Yes, leaking into user programs is a bad practice. Is there a
solution/patch for that?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Bruce Momjian wrote:

PostgreSQL would probably "play" better with other products if
the DEBUG macro had a prefix, maybe PGSQLDEBUG or similar.

Until there is some fix in this area, plperl will not build with
a version of perl that has debugging enabled.

It even got on my nerves (linux, ecpg) since I used to define a macro
#define DEBUG(x) cout << x
or
#define DEBUG(x)

DEBUG and ERROR are far too common to get defined for client programs.

But perhaps it is ecpg's fault for including "elog.h".
IMHO these defines should never leave the database kernel.

perhaps the common
#ifdef _DBKERNEL_
#endif
would do the trick.

Christof

PS: Having Datum unconditionally leaked to ecpg programs forced me to preced
a namespace to my own class.

Yes, leaking into user programs is a bad practice. Is there a
solution/patch for that?

A solution would be a simple patch which is not available yet. But I
plan on
doing one (some other things still have higher priority).

Christof

On Sun, Oct 08, 2000 at 01:37:45PM -0400, Bruce Momjian wrote:

But perhaps it is ecpg's fault for including "elog.h".
IMHO these defines should never leave the database kernel.

...
Yes, leaking into user programs is a bad practice. Is there a
solution/patch for that?

Hmm, I haven't check carefully, but I don't think ecpg include elog.h
directly. Maybe I just picked the wrong file to include.

Michael
--
Michael Meskes
Michael@Fam-Meskes.De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!