Re: [HACKERS] snprintf() argument reordering not working under Windows in 8.1

Greetings,

I thought it will be as simple as changing Makefile, the issue seem to be
much more complicated. Unfortunately I have no PostgreSQL building
environment handy and will not be able to look at it until the end of next
week because I am moving my house :( But since this issue waited for so
long it may wait a week more.

2005/12/3, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>:
> Sure, I remember. So glad you returned at this time. I found a design
> limitation in that file yesterday. It can not output more then 4096
> characters, and there are some cases with NUMERIC that try to output
> more than that. For example:
>
> SELECT pow(10::numeric, 10000) + 1;
>
> should show a '1' at the end of the number, but with the existing code
> you will just see 4095 0's and no more.
>
> I am attaching the new snprintf.c and the patch itself for your review.
> The change is to pass 'stream' down into the routines and output to the
> FILE* right from inside the routine, rather than using a string. This
> fixes the problem.

Your patch increase buffers from 4095 to 8192. Sounds good to me.

> I am also thinking of modifying the code so if we are using snprintf.c
> only because we need positional parameter control, we check for '$' in
> the string and only use snprintf.c in those cases.

I too, was thinking of it at the beginning but decided that the code would
get even more complicated than it was at the moment and was afraid that
core team would not accept my patch. :)

> > NLS messages of some languages, like Turkish, rely heavily on argument
> > reordering because of the language structure. In 8.1 Turkish messages
> > in Windows version are all broken because argument reordering is not there.
>
> Really? I have not heard any report of that but this is new code in 8.1.

Windows installer does not set lc_messages configuration variable
correctly in postgresql.conf file. It is a known issue and will be solved
in next version. Meanwhile user needs to open postgresql.conf file
and change

lc_messages = 'Turkish_Turkey.28599'
to
lc_messages = 'tr_TR.UTF-8'

manually. Apparently nobody cared to do it and Devrim never ever touches
Windows. The problem is there, I am definitely positive about it, here are
two lines from log file:

2005-11-20 12:36:37 HATA: "$s" yerinde $s 1 karakterinde
2005-12-03 19:14:27 LOG: "$s" veritabanın transaction ID warp limiti $u

>
> Actually, that changes means that there was nothing backend-specific in
> snprintf.c so we don't need a _special_ version for the backend. The
> real change not to use snprintf.c on Win32 is in configure.in with this
> comment:
>
> # Force use of our snprintf if system's doesn't do arg control
> # This feature is used by NLS
> if test "$enable_nls" = yes &&
> test $pgac_need_repl_snprintf = no &&
> # On Win32, libintl replaces snprintf() with its own version that
> # understands arg control, so we don't need our own. In fact, it
> # also uses macros that conflict with ours, so we _can't_ use
> # our own.
> test "$PORTNAME" != "win32"; then
> PGAC_FUNC_PRINTF_ARG_CONTROL
> if test $pgac_cv_printf_arg_control != yes ; then
> pgac_need_repl_snprintf=yes
> fi
> fi
>
> Here is the commit:
>
> revision 1.409
> date: 2005/05/05 19:15:54; author: momjian; state: Exp; lines: +8 -2
> On Win32, libintl replaces snprintf() with its own version that
> understands arg control, so we don't need our own. In fact, it
> also uses macros that conflict with ours, so we _can't_ use
> our own.

I don't have MinGW build environment on my computer at the moment
and will not be able to install it until the end of next week but log messages
above were produced by PostgreSQL installed with 8.1.0-2 Windows installer
downloaded from postgresql.org. Since Turkish messages are printed
I suppose it was compiled with $enable_nls = yes

Thank you for your attention,
Regards,
Nicolai Tufar