> > The proper fix is probably to include the client encoding in the
> connection
> > startup message.
>
> What of errors occurring before such an option could be applied?
>
> I think that ultimately it's necessary to accept that there will be some
> window during connection startup where sending plain ASCII (English)
> messages is the best recourse. I'm not sure what the best way to
> implement that is. On reflection though, trying to mark the individual
> messages that might need that treatment doesn't seem like a winner:
> there's too much possibility for mistakes, or code drift causing a
> marking to become wrong; and I'm not even convinced that the very same
> source-code message might not fall into both categories at different
> times. So having a mode switch somehow occurring inside elog.c once
> we are ready to translate seems like the right approach.
Hm, so maybe both Peter and Alvaro are right:
1) Setting the translation wrapper to a NOOP as early as possible.
Thus, the first messages are sent in 7-bit ASCII English.
2) Including the server encoding in the very (?) first message sent to the
client *after* which ...
3) ... proper initialization of the gettext system can happen because now
the client can know what to make of them subsequent messages.
Thereby no strings should need special marking and proper translation or
not is achieved automatically ?
It is surely acceptable to see the very first messages in English and/or
7-bit ASCII - I just want to be able to know their encoding either by definition
or by being told.
Thanks,
Karsten
--
Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL
für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
