Re: Suggested change in include/utils/elog.h
От | Bruce Momjian |
---|---|
Тема | Re: Suggested change in include/utils/elog.h |
Дата | |
Msg-id | 200010081737.NAA12468@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Suggested change in include/utils/elog.h (Christof Petig <christof.petig@wtal.de>) |
Ответы |
Re: Suggested change in include/utils/elog.h
|
Список | 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, Pennsylvania19026
В списке pgsql-hackers по дате отправления: