Peter Eisentraut <peter_e@xxxxxxx> writes: > On Wednesday 31 December 2008 18:57:29 Karsten Hilbert wrote: >> The solution is to find the right layer to take control of the encoding but >> this is eventually only possible if the encoding is *known*. Thus the plea >> for "7-bit-ascii English by default until the encoding *can* be known". >> Going to "7-bit-ascii filter of the original by default until the encoding >> can be known" only tries to preserve a bit more of the original language. I >> may be wrong in feasibility. > 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. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
