Thread: 4 hour countdown

At ~16:00 ADT this afternoon, I will branch, tag and package up 8.0.0 ... 
if anyone has any 'show stoppers', let us know within the next 4 hours :)

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

Sorry for such a late submission.

I just downloaded the latest postgresql-8.0.0-rc5-3.zip installer
for windows and it appears that Windows' printf() does not
support placeholder replacement as described in
http://developer.postgresql.org/docs/postgres/nls.html#AEN57284

I searched list archives but found no explanation for this.
Original string is <<%s at or near \"%s\">> and we
replaced it in Turkish for <<\"%2$s\"  yerinde %1$s>>.

It works perfectly fine on Linux but fails miserably under
Windows with something like:
<<HATA:  "$s"  yerinde $sat character 1>>
    while on Linux the same version works fine:
<<HATA: "sdfassfsdfasd" yerinde söz dizim hatasý at character 1 >>

What is it? I suppose that Windows' printf() does
not support changing the order of placeholder
characters with %2$ .... %1$. Did some one else
deal with it? Is it because of compilation flags?

In any case PostgreSQL version in current pginstaller
is broken.

Best regards,
Nicolai

unix/win32 libc doesnt support "$n" variables..


On Mon, 17 Jan 2005 21:03:56 +0200, Nicolai Tufar <ntufar@gmail.com> wrote:
> Sorry for such a late submission.
>
> I just downloaded the latest postgresql-8.0.0-rc5-3.zip installer
> for windows and it appears that Windows' printf() does not
> support placeholder replacement as described in
> http://developer.postgresql.org/docs/postgres/nls.html#AEN57284
>
> I searched list archives but found no explanation for this.
> Original string is <<%s at or near \"%s\">> and we
> replaced it in Turkish for <<\"%2$s\"  yerinde %1$s>>.
>
> It works perfectly fine on Linux but fails miserably under
> Windows with something like:
> <<HATA:  "$s"  yerinde $sat character 1>>
>     while on Linux the same version works fine:
> <<HATA: "sdfassfsdfasd" yerinde söz dizim hatasý at character 1 >>
>
> What is it? I suppose that Windows' printf() does
> not support changing the order of placeholder
> characters with %2$ .... %1$. Did some one else
> deal with it? Is it because of compilation flags?
>
> In any case PostgreSQL version in current pginstaller
> is broken.
>
> Best regards,
> Nicolai
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>


--
/* Jumping Flowers */

On Mon, 17 Jan 2005 16:17:33 -0300, Fx <weimaraner@gmail.com> wrote:
> unix/win32 libc doesnt support "$n" variables..

What can we do then?

Nicolai Tufar <ntufar@gmail.com> writes:
> Sorry for such a late submission.
> I just downloaded the latest postgresql-8.0.0-rc5-3.zip installer
> for windows and it appears that Windows' printf() does not
> support placeholder replacement as described in
> http://developer.postgresql.org/docs/postgres/nls.html#AEN57284

> Original string is <<%s at or near \"%s\">> and we
> replaced it in Turkish for <<\"%2$s\"  yerinde %1$s>>.

Hmm.  Looking around, it seems that %n$ support is required by the
Single Unix Spec:
http://www.opengroup.org/onlinepubs/007908799/xsh/fprintf.html
but it is *not* required by C99 as far as I can tell.  I don't see any
mention of support for it in my HPUX fprintf man page, either.  So this
construct may not be as portable as we could wish.

There appear to be about 150 affected messages, in these files:

src/backend/po/pt_BR.po
src/backend/po/de.po
src/backend/po/es.po
src/backend/po/zh_CN.po
src/backend/po/tr.po
src/bin/pg_dump/po/zh_CN.po
src/bin/pg_dump/po/tr.po
src/bin/psql/po/zh_CN.po
src/bin/psql/po/zh_TW.po
src/bin/psql/po/tr.po
src/bin/scripts/po/zh_CN.po

I don't think we'll hold up release to fix this, but the affected
translators may want to think about whether they can avoid the problem
or not.

            regards, tom lane

I wrote:
> I don't think we'll hold up release to fix this, but the affected
> translators may want to think about whether they can avoid the problem
> or not.

Also, it looks like src/port/snprintf.c is not %n$ capable either.
I'm not sure which platforms that affects.

A possible route to a solution is to upgrade snprintf.c and then use
it on platforms that don't have this support.  This only fixes those
cases where we go through snprintf, which is probably not all of the
affected messages, but it might be enough.  It's not happening for
8.0.0 though.

            regards, tom lane

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi,

On Mon, 17 Jan 2005, Tom Lane wrote:

<snip>
> I don't think we'll hold up release to fix this,

:-) It seems nothing seems to stop you from holding up this release 
anymore: Neither ARC problem nor this one :)

Regards,
- --
Devrim GUNDUZ 
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.tdmsoft.com                         http://www.gunduz.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFB7B0Ktl86P3SPfQ4RAqCFAJ9YLdaUP8ALAetKHQcpPxHfrlcXcQCgpKmX
gKsYQYdu8nh4rGQOo2DQl3c=
=g6q/
-----END PGP SIGNATURE-----

On Mon, 17 Jan 2005 14:54:44 -0500, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Also, it looks like src/port/snprintf.c is not %n$ capable either.
> I'm not sure which platforms that affects.
>
> A possible route to a solution is to upgrade snprintf.c and then use
> it on platforms that don't have this support.  This only fixes those
> cases where we go through snprintf, which is probably not all of the
> affected messages, but it might be enough.  It's not happening for
> 8.0.0 though.

Bad news for the Turks. Turkish language syntax
is lake Latin: the verb is always at the end. Because
of that almost all messages that have two or more
placeholders are broken under Windows.

The solution you propose seem to be a trivial exercise:
1. write a replacement function, say, pg_snprintf() that
    would shuffle input arguments, replace %x$ with %
    and then call libc's snprintf();
2. replace snprintf() in all source files with pg_snprintf();
3. Update Makefiles to use our custom function on broken
    platforms or default to snprinf(). (Or maybe pg_snprintf()
    should be a #define);
4. Tell everyone to use pg_snprintf() instead of snprintf()
     from now on.

I would like volunteer to implement this for 8.1 and
would be honoured if I get a chance to contribute.

>                         regards, tom lane

Best regards,
Nicolai Tufar