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:
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
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
CREATE TABLE
Peter Eisentraut pete...@gmx.net 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
Peter Eisentraut pete...@gmx.net 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
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
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 was
Tatsuo Ishii is...@postgresql.org 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
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
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
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, 0x83, 0x88)
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 cause
12 matches
Mail list logo
