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.
> > 
> 
> 
> -- 
>   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
> 

Sat, 30 Sep 2000 10:28:53 +0200
Magnus Hagander <mha@sollentuna.net>
RE: Suggested change in include/utils/elog.h
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.



Mon, 02 Oct 2000 23:54:46 +0200
Christof Petig <christof.petig@wtal.de>
Re: Suggested change in include/utils/elog.h
> > > > 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

Sun, 8 Oct 2000 13:37:45 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Suggested change in include/utils/elog.h
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

Mon, 09 Oct 2000 12:50:26 +0200
Christof Petig <christof.petig@wtal.de>
Re: Suggested change in include/utils/elog.h
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!

Tue, 10 Oct 2000 15:47:15 -0700
Michael Meskes <meskes@postgresql.org>
Re: Suggested change in include/utils/elog.h