Обсуждение: 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