> I confirmed the problem. Also I confirmed your patch fixes the
> problem. In addition to this, all the tests in test/mb and
> test/regress are passed.
Fix committed as you proposed(without any message I proposed). Thanks.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/inde
Tatsuo Ishii writes:
>> TBH I think that a message here is unnecessary; it's sufficient to
>> ensure psql doesn't crash. The backend will produce a better message
>> than this anyway once the data gets there, and that way we don't have to
>> invent a new error recovery path inside psql. As-is, t
> I think the message should be more precise. Nobody will know what an
> "encoding conflict" is. The error condition is "last multibyte
> character ran over end of file" or something like that, which should be
> clearer.
"last multibyte character ran over" is not precise at all because the
error
> I wonder about the "possible".
>
> Could there be false positives with the test?
> If yes, I don't like the idea.
Yes, there could be false positives. It was just because the input
file was broken. In the real world, I think probably encoding mismatch
is the most possible cause, but this is not
> Peter Eisentraut writes:
>> On 11/30/12 3:26 AM, Albe Laurenz wrote:
>>> If there is no possibility for false positives, I'd say
>>> that the "possible" should go. Maybe it should even be
>>> an error and no warning then.
>
>> Yes, encoding mismatches are generally an error.
>
>> I think the
Peter Eisentraut writes:
> On 11/30/12 3:26 AM, Albe Laurenz wrote:
>> If there is no possibility for false positives, I'd say
>> that the "possible" should go. Maybe it should even be
>> an error and no warning then.
> Yes, encoding mismatches are generally an error.
> I think the message shou
On 11/30/12 3:26 AM, Albe Laurenz wrote:
> Tatsuo Ishii wrote:
>> postgres=# \i ~/sql
>> CREATE DATABASE
>> You are now connected to database "mydb" as user "t-ishii".
>> CREATE SCHEMA
>> psql:/home/t-ishii/sql:7: warning: possible conflict between client
> encoding SJIS and input file
>> encoding
Tatsuo Ishii wrote:
> I think we should detect the cases as much as possible and warn users,
> rather than silently ignore that fact client encoding != file
> encoding. I don't think we can detect it in a reliable way, but at
> least we could check the cases above(sum of PQmblen is not equale to
>
> buffer lenghth). So my proposal is, if prepare_buffer() detects
> possible inconsistency between buffer encoding and file encoding, warn
> user.
I agree with that.
On 2012/11/30 12:52, Tatsuo Ishii Wrote:
1. some especial character
(my sql file contains japanese comment "-- コメント" . It can ca
>> 1. some especial character
>> (my sql file contains japanese comment "-- コメント" . It can cause
>> psql crash.)
>> 2. PGCLIENTENCODING is SJIS
>> 3. the encoding of input sql file is UTF-8
Actually the problem can occur even when importing following 3 byte
UTF8 input file:
ト
(in hexa, 0xe3, 0x
I confirmed the problem. Also I confirmed your patch fixes the
problem. In addition to this, all the tests in test/mb and
test/regress are passed.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
> hi
>
> When i test psql under m
hi
When i test psql under multi-lingual and different encoding environment,
I found a crash of psql.
--
$ export PGCLIENTENCODING=SJIS
$ psql
psql (9.2rc1)
Type "help" for help.
postgres=# \i sql
CREATE DATABASE
You are now con
12 matches
Mail list logo
