Horton

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

Bruce Momjian <pgman@candle.pha.pa.us>

View thread
From: Bruce Momjian <pgman@candle.pha.pa.us>
To: Christof Petig <christof.petig@wtal.de>
Cc: Magnus Hagander <mha@sollentuna.net>, "David R. Favor" <dfavor@austin.ibm.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Michael Meskes <meskes@postgresql.org>
Date: 2000-10-08T17:37:45Z
Lists: pgsql-hackers 
> > > > 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