Re: BUG #7493: Postmaster messages unreadable in a Windows console - Mailing list pgsql-hackers

<div class="moz-cite-prefix">Hello, </div><blockquote cite="mid:20130210210259.GA7401@tornado.leadboat.com"
type="cite"><blockquotetype="cite"><blockquote type="cite"><blockquote type="cite"><pre wrap="">Alexander Law <a
class="moz-txt-link-rfc2396E"href="mailto:exclusion@gmail.com"><exclusion@gmail.com></a> writes:
 
</pre><blockquote type="cite"><pre wrap="">Please look at the following l10n bug:
<a class="moz-txt-link-freetext"
href="http://www.postgresql.org/message-id/502A26F1.6010109@gmail.com">http://www.postgresql.org/message-id/502A26F1.6010109@gmail.com</a>
and the proposed patch.
</pre></blockquote></blockquote></blockquote></blockquote><pre wrap="">
With your proposed change, the problem will resurface in an actual SQL_ASCII
database.  At the problem's root is write_console()'s assumption that messages
are in the database encoding.  pg_bind_textdomain_codeset() tries to make that
so, but it only works for encodings with a pg_enc2gettext_tbl entry.  That
excludes SQL_ASCII, MULE_INTERNAL, and others.  write_console() needs to
behave differently in such cases.</pre></blockquote> Thank you for the notice. So it seems that "DatabaseEncoding"
variablealone can't present a database encoding (for communication with a client) and current process messages encoding
(forlogging messages) at once. There should be another variable, something like CurrentProcessEncoding, that will be
setto OS encoding at start and can be changed to encoding of a connected database (if bind_textdomain_codeset
succeeded).<br/><br /><blockquote cite="mid:20130214024020.GA28577@tornado.leadboat.com" type="cite"><div
class="moz-text-plain"graphical-quote="true" lang="x-western" style="font-family: -moz-fixed; font-size: 12px;"
wrap="true"><prewrap="">On Tue, Feb 12, 2013 at 03:22:17AM +0000, Greg Stark wrote:
 
</pre><blockquote style="color: #000000;" type="cite"><pre wrap=""><span class="moz-txt-citetags">> </span>But that
saidI'm not sure saying the whole file is in an encoding is
 
<span class="moz-txt-citetags">> </span>the right approach. Paths are actually binary strings. any encoding is
<span class="moz-txt-citetags">> </span>purely for display purposes anyways.
</pre></blockquote><pre wrap="">For Unix, yes.  On Windows, they're ultimately UTF16 strings; some system APIs
accept paths in the Windows ANSI code page and convert to UTF16 internally.
Nonetheless, good point.
</pre></div></blockquote> Yes, and if postresql.conf not going to be UTF16 encoded, it seems natural to use ANSI code
pageon Windows to write such paths in it.<br /> So the paths should be written in OS encoding, which is accepted by OS
functions,such as fopen. (This is what we have now.)<br /> And it seems too complicated to have different encodings in
onefile. Or maybe path parameters should be separated from the others, for which OS encoding is undesirable.<br
/><blockquotecite="mid:CAM-w4HOpZfoaXwS8Tb114XaXS=3psLBFqaWb0ZZFG2keS+CbdQ@mail.gmail.com" type="cite"><blockquote
type="cite"><prewrap="">If we knew that postgresql.conf was stored in, say, UTF8, then it would
 
probably be possible to perform encoding conversion to get string
variables into the database encoding.  Perhaps we should allow some
magic syntax to tell us the encoding of a config file?
       file_encoding = 'utf8'  # must precede any non-ASCII in the file
</pre></blockquote><pre wrap="">If we're going to do that we might as well use the Emacs standard
-*-coding: latin-1;-*-


</pre></blockquote> Explicit encoding specification such as these (or even <?xml version="1.0"
encoding="utf-8"?>)can be useful but what encoding to assume without it? For XML (without BOM) it's UTF-8, for emacs
itdepends on it's language environment.<br /> If postgresql.conf doesn't have to be portable (as XML), then IMO OS
encodingis the right choice for it.<br /><br /><br /> Best regards,<br /> Alexander<br />