Re: [pgsql-hackers-win32] snprintf causes regression tests
От | Bruce Momjian |
---|---|
Тема | Re: [pgsql-hackers-win32] snprintf causes regression tests |
Дата | |
Msg-id | 200503030003.j23032x28306@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [pgsql-hackers-win32] snprintf causes regression tests to fail (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [pgsql-hackers-win32] snprintf causes regression tests to fail
|
Список | pgsql-hackers |
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Tom Lane wrote: > >> First line of thought: we surely must not insert a snprintf into > >> libpq.so unless it is 100% up to spec *and* has no performance issues > >> ... neither of which can be claimed of the CVS-tip version. > > > Agreed, and we have to support all the 64-bit specifications a port > > might support like %qd and %I64d as well as %lld. I have added that to > > our current CVS version. > > I really dislike that idea and request that you revert it. Done. > > Is there any way we can have just gettext() call our snprintf under a > > special name? > > The issue only comes up in libpq --- in the backend there is no reason > that snprintf can't be our snprintf, and likewise in self-contained > programs like psql. It might be worth the pain-in-the-neck quality to > have libpq refer to the functions as pq_snprintf etc. Perhaps we could > do this via macros > > #define snprintf pq_snprintf > > and not have to uglify the source code. Yes, this is what I was thinking of too. I think it would need a macro in libpq to map the libc names to the pq_* names, and a separate /port C file that maps the normal libc names to the pg_* names. For client applications and the backend, this new C file would catch all the snprintf calls, while for libpq the pg_* calls would be used directly and the new C file with the libc symbols would not be pulled in. Does that sound like a plan? The reason we can't just use the macro everwhere is that we don't want applications using libpq to all be using pg_* functions, only psql and our own. The only other solution I can think of is to make sure all client apps use FRONTEND as a define and trigger the macros from libc names to pg_* names on that. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
В списке pgsql-hackers по дате отправления: