Обсуждение: RE: Suggested change in include/utils/elog.h
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 >
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.
> > > > 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, Pennsylvania19026
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
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.
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!