Hi Noah,
Thank you for your review.
I agree with you, CONOUT$ way is much simpler. Please look at the patch.
Regarding msys - yes, that check was not correct.
In fact you can use "con" with msys, if you run sh.exe, not a graphical
terminal.
So the issue with con not related to msys, but to some
Hello,
while trying to set consistent log encoding (following the discussion
http://archives.postgresql.org/message-id/5006D340.4000808%40gmail.com),
I discovered a few bugs, that IMHO should be fixed before.
When I disable logging collector and try to run postmaster in a command
line, I get no
I like Craig's idea of adding the client encoding to the log lines. A
possible problem with that (I'm not an encoding expert) is that a log
line like that will contain data about the database server meta-data
(log time, client encoding, etc) in the database default encoding and
database data (the
Sorry, it was inaccurate phrase. I mean "if the conversion to this
encoding is not avaliable". For example, when we have database in
EUC_JP and log_encoding set to Latin1. I think that we can even fall
back to UTF-8 as we can convert all encodings to it (with some
exceptions that you noticed).
Ok, maybe the time of real universal encoding has not yet come. Then
we maybe just should add a new parameter "log_encoding" (UTF-8 by
default) to postgresql.conf. And to use this encoding consistently
within logging_collector.
If this encoding is not available then fall back to 7-bit ASCII.
What
And regarding mule internal encoding - reading about Mule
http://www.emacswiki.org/emacs/UnicodeEncoding I found:
/In future (probably Emacs 22), Mule will use an internal encoding
which is a UTF-8 encoding of a superset of Unicode. /
So I still see UTF-8 as a common denominator for all the enco
The initial issue was that log file contains messages in different
encodings. So transcoding is performed already, but it's not
This is not true. Transcoding happens only when PostgreSQL is built
with --enable-nls option (default is no nls).
I'll restate the initial issue as I see it.
I have Win
Hello,
Implementing any of these isn't trivial - especially making sure
messages emitted to stderr from things like segfaults and dynamic
linker messages are always correct. Ensuring that the logging
collector knows when setlocale() has been called to change the
encoding and translation of s
Hello,
C. We have one logfile with UTF-8.
Pros: Log messages of all our clients can fit in it. We can use any
generic editor/viewer to open it.
Nothing changes for Linux (and other OSes with UTF-8 encoding).
Cons: All the strings written to log file should go through some
conversation function.
Hello!
May I to propose a solution and to step up?
I've read a discussion of the bug #5800 and here is my 2 cents.
To make things clear let me give an example.
I am a PostgreSQL hosting provider and I let my customers to create any
databases they wish.
I have clients all over the world (so they
ed on the website:
Bug reference: 6742
Logged by: Alexander LAW
Email address: exclusion(at)gmail(dot)com
PostgreSQL version: 9.1.4
Operating system: Windows
Description:
When I try to dump database with UTF-8 encoding in Windows, I get unreadable
object
Thanks, I've understood your point.
Please look at the patch. It implements the first way and it makes psql
work too.
Regards,
Alexander
20.03.2012 00:05, Alvaro Herrera пишет:
Excerpts from Alexander LAW's message of dom mar 18 06:04:51 -0300 2012:
I see two ways to resolve the issue.
First
I see two ways to resolve the issue.
First is to use CharToOemBuff when writing a string to the "con" and
OemToCharBuff when reading an input from it.
The other is to always use stderr/stdin for Win32 as it was done for
msys before. I think it's more straightforward.
I tested the attached patch
Thank you, Tom.
I tried patched file and it works fine now (with Russian locale both in
Linux and Windows).
I've noticed that you strict mon_decimal_point to one char, but at least
two locales (fa_IR and ps_AF) (I looked at glibc-2.14) define
mon_decimal_point as "" so it takes two bytes.
And I
The following bug has been logged online:
Bug reference: 6277
Logged by: Alexander LAW
Email address: exclus...@gmail.com
PostgreSQL version: 9.1.1
Operating system: Windows
Description:Money datatype conversion wrong with Russian locale
Details:
When lc_monetary
15 matches
Mail list logo
