Re: [pgsql-hackers-win32] snprintf causes regression tests

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Have we considered what is going to happen to applications when they use
> > our snprintf instead of the one from the operating system?
>
> Hmm ...
>
> 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.

> Second line of thought: libpq already feels free to insert allegedly
> up-to-spec versions of a number of things, and no one has complained.
> Maybe the linker prevents problems by not linking these versions to
> any calls from outside libpq?

I just tested on BSD/OS and a program with a single printf() call does
call our printf if libpq is used on the link line. The program makes no
libpq calls at all.

> Third thought: Windows' linker seems to be broken enough that it may
> create problems of this ilk that exist on no other platform.

Yes, strangly the Window's linker is fine because libpqdll.def defines
what symbols are exported. I don't think Unix has that capability.

Is there any way we can have just gettext() call our snprintf under a
special name?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073