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 ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]