Re: Suggested change in include/utils/elog.h
Christof Petig <christof.petig@wtal.de>
From: Christof Petig <christof.petig@wtal.de>
To: Bruce Momjian <pgman@candle.pha.pa.us>
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-09T10:50:26Z
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