From: Noah Misch [mailto:n...@leadboat.com]
Sent: Thursday, July 19, 2012 5:23 PM
On Tue, Jul 17, 2012 at 08:59:50AM +, Amit kapila wrote:
>> Patch is attached with this mail.
> Thanks. This patch is ready for committer.
>> +-- Test non-inheritable indices [UNIQUE, EXCLUDE] contraints
>> +C
spatar...@yahoo.com writes:
> I use "UTF8" charset and "Romania, Romanian" locale.
> I came across this as I wanted to test if a symbol was a letter:
> SELECT 'a' BETWEEN 'a' AND 'z'; -- true
> SELECT 'z' BETWEEN 'a' AND 'z'; -- true
> SELECT 'A' BETWEEN 'a' AND 'z'; -- true
> SELECT 'Z' BETWEEN
On 07/19/2012 04:58 PM, Alban Hertroys wrote:
On 19 July 2012 10:40, Alexander Law wrote:
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
wit
On 07/19/2012 03:24 PM, Tatsuo Ishii wrote:
BTW, I'm not stick with mule-internal encoding. What we need here is a
"super" encoding which could include any existing encodings without
information loss. For this purpose, I think we can even invent a new
encoding(maybe something like very first prpo
On 19 July 2012 13:50, Alexander Law wrote:
>> 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)
On Tue, Jul 17, 2012 at 08:59:50AM +, Amit kapila wrote:
> Patch is attached with this mail.
Thanks. This patch is ready for committer.
> +-- Test non-inheritable indices [UNIQUE, EXCLUDE] contraints
> +CREATE TABLE test_constraints (id int, val1 varchar, val2 int, UNIQUE(val1,
> val2));
>
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).
Yikes, messed up my grammar a bit I see!
On 19 July 2012 10:58, Alban Hertroys wrote:
> 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-
On 19 July 2012 10:40, Alexander Law wrote:
>>> 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 thi
> 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 noti
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
>> You can google by "encoding "EUC_JP" has no equivalent in "UTF8"" or
>> some such to find such an example. In this case PostgreSQL just throw
>> an error. For frontend/backend encoding conversion this is fine. But
>> what should we do for logs? Apparently we cannot throw an error here.
>>
>> "Un
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 tra
>> I am thinking about variant of C.
>>
>> Problem with C is, converting from other encoding to UTF-8 is not
>> cheap because it requires huge conversion tables. This may be a
>> serious problem with busy server. Also it is possible some information
>> is lossed while in this conversion. This is be
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
18 matches
Mail list logo
