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

From: Christof Petig <christof(dot)petig(at)wtal(dot)de>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Magnus Hagander <mha(at)sollentuna(dot)net>, "David R(dot) Favor" <dfavor(at)austin(dot)ibm(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Michael Meskes <meskes(at)postgresql(dot)org>
Subject: Re: Suggested change in include/utils/elog.h
Date: 2000-10-09 10:50:26
Message-ID: 39E1A2F2.7C0E3DB1@wtal.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Martin A. Marques 2000-10-09 11:26:50 Re: backup and restore
Previous Message Bruce Momjian 2000-10-09 07:36:52 Re: C++ client libs