Nicolai Tufar wrote:
> On Thu, 10 Mar 2005 16:26:47 -0500 (EST), Bruce Momjian
> <pgman@candle.pha.pa.us> wrote:
> > Please see my posting about using a macro for snprintf. If the current
> > implementation of snprintf is enough for our existing translation users
> > we probably don't need to add anything more to it because snprintf will
> > not be exported to client applications.
>
> Oh, Bruce. It will be the best solution. I was worried about
> the problems with my modifications to snprintf.c Tom Lane
> pointed out. But if we really separate snprintf() used by
> messages and snprintf() used by the like of
> src/backend/utils/adt/int8.c then we are safe. We can claim
> current release safe and I will modify src/port/snprintf.c at my
> leisure later. I will try out your modifications tomorrow. It
> is late here and I have a PostgreSQL class to to teach
> tomorrow ;)
>
> I still think that it is more convenient to rip off current
> implementation of snprintf.c and replace it with a very much
> stripped down of Trio's one. I will work on it and try to get
> a patch in one week's time. Thank you all for your patience.
I am not heading in the direction of using a different snprintf for
messages and for int8.c. I am just renaming the calls via macros so we
don't leak snprintf from libpq.
One new idea I had was to have pg_snprintf() look over the format string
and adjust the arguments to match what the format string is requesting,
remove %$ from the format string, and then pass it to the native libc
snprintf(). That might be the easiest solution for the many platforms
with a good snprintf but not %$ support.
Is that possible/easier?
--
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
