Tom Lane wrote:
>Andrew Dunstan <andrew@dunslane.net> writes:
>
>
>>What is more, when I set the locale of my machine to Turkish and run the
>>installer project's 8.1_RC1 which I happen to have installed there, and
>>set lc_messages to tr_TR.UTF-8, I don't see lines like Nicolai reported:
>> LOG: "$s" veritaban?n transaction ID warp limiti $u
>>I see this:
>> LOG: "2147484146" veritabanin transaction ID warp limiti postgres
>>
>>
>
>Well, that's pretty broken too :-(. The tr.po file entry is
>
> msgid "transaction ID wrap limit is %u, limited by database \"%s\""
> msgstr "\"%2$s\" veritabanın transaction ID warp limiti %1$u"
>
>and if I'm not completely confused, correct translated output would be
>
> "postgres" veritabanın transaction ID warp limiti 2147484146
>
>Nicolai's report looks a bit like what you would expect from an sprintf
>implementation that hadn't heard of %n$ specs at all. Your report looks
>suspiciously like what our broken version of sprintf was producing last
>week --- see
>http://archives.postgresql.org/pgsql-hackers/2005-12/msg00194.php
>
>How certain are you that that config setting is inhibiting use of
>port/snprintf.c? It seems unlikely that any other implementation would
>have duplicated our bug.
>
>
Sorry ... I got into a muddle. I have rerun the tests.
With 8.1_RC1 I *do* get the results Nicolai reported. With the changes I
made yesterday, I see the result above, i.e. what we expect from our own
breakage of sprintf (i haven't yet updated the snapshot I took). I will
now try to verify that the changes you made in pg_sprintf do the right
thing.
We could ask why it appears that one version of libintl works (the one I
got the other day from gnuwin32) and one doesn't (the one that is in the
installer, apparently).
But the simple fix seems to be to use our version of printf and friends.
The changes requires are not too invasive.
cheers
andrew