| From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
|---|---|
| To: | Christof Petig <christof(dot)petig(at)wtal(dot)de> |
| 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-08 17:37:45 |
| Message-ID: | 200010081737.NAA12468@candle.pha.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| 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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alfred Perlstein | 2000-10-08 18:02:40 | Re: Still crashing with latest 7.0.2 (Re: (forw) more crashes) |
| Previous Message | Chris | 2000-10-08 10:56:40 | Re: inheritance question 2/ref integrity |