[BUGS] BUG #3638: UTF8 Character encoding does NOT work

2007-09-27 Thread Fil Matthews
The following bug has been logged online: Bug reference: 3638 Logged by: Fil Matthews Email address: [EMAIL PROTECTED] PostgreSQL version: 8-1, 8-2 Operating system: Linux Debian - Windows XP Description:UTF8 Character encoding does NOT work Details: Judging f

Re: [BUGS] BUG #3638: UTF8 Character encoding does NOT work

2007-09-27 Thread Tatsuo Ishii
Why do you think that an UTF-8 encoded string starting with 0x92 is valid? 0x92 can appear in the second, third or fourth octet, but should never appear in the first octet. -- Tatsuo Ishii SRA OSS, Inc. Japan > The following bug has been logged online: > > Bug reference: 3638 > Logged by:

Re: [BUGS] BUG #3638: UTF8 Character encoding does NOT work

2007-09-27 Thread Heikki Linnakangas
Fil Matthews wrote: > Come on are you serious?? .. Just how does one work with completly valid > data that has an ascii 128 + value ?? A string with a single byte that has high-bit set (characters 128-255) is *not* a valid UTF-8 sequence. That's why you get the error. One could argue that chr(14

Re: [BUGS] BUG #3638: UTF8 Character encoding does NOT work

2007-09-27 Thread Gregory Stark
"Fil Matthews" <[EMAIL PROTECTED]> writes: > In Short A Postgres UTF8 database .. PGCLIENENCODING=UTF8 ... > Insert into test values ( chr(146));; Can you explain what you expected to happen here? Did you, for example, expect the character with Unicode code point 146 to be inserted? Because the

[BUGS] BUG #3639: queryplanner degrades to a sequential scan even if there's an index

2007-09-27 Thread Hannu Valtonen
The following bug has been logged online: Bug reference: 3639 Logged by: Hannu Valtonen Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.4 Operating system: Debian Linux (4.0), kernel 2.6.20 Description:queryplanner degrades to a sequential scan even if there'

Re: [BUGS] BUG #3639: queryplanner degrades to a sequential scan even if there's an index

2007-09-27 Thread Heikki Linnakangas
Hannu Valtonen wrote: > explain analyze select * from table1, table2 where table1.table2_id = > table2.id and table2.id = 2841962; Here the planner is using the partial index table2_id_index on table1, knowing that table1.table2_id equals 2841962, satisfying the "NOT (table2_id = 1)" condition tha

Re: [BUGS] BUG #3639: queryplanner degrades to a sequential scan even if there's an index

2007-09-27 Thread Hannu Valtonen
Heikki Linnakangas kirjoitti: Hannu Valtonen wrote: explain analyze select * from table1, table2 where table1.table2_id = table2.id and table2.id = 2841962; Here the planner is using the partial index table2_id_index on table1, knowing that table1.table2_id equals 2841962, satisfying t

Re: [BUGS] CREATE USER and createuser not working the same

2007-09-27 Thread Stéphane Schildknecht
Alvaro Herrera a écrit : > Cédric Villemain wrote: > >> Le jeudi 13 septembre 2007, Tom Lane a écrit : >> >>> =?ISO-8859-1?Q?St=E9phane_Schildknecht?= >>> >> <[EMAIL PROTECTED]> writes: >> It seems the shell command createuser and the SQL CREATE USER don't act the sam

Re: [BUGS] BUG #3638: UTF8 Character encoding does NOT work

2007-09-27 Thread Tatsuo Ishii
> Tatsuo Ishii wrote: > > Why do you think that an UTF-8 encoded string starting with 0x92 is > > valid? > > > > 0x92 can appear in the second, third or fourth octet, but should never > > appear in the first octet. > > -- > > Tatsuo Ishii > > SRA OSS, Inc. Japan > > > > > >> The following bug ha

Re: [BUGS] BUG #3638: UTF8 Character encoding does NOT work

2007-09-27 Thread Tatsuo Ishii
> Then how then does Postgres expect to be able to store text that goes > beyond SQL_ASCII.. ??? Because what you are saying in effect is that If you need to store an arbitrary byte sequences, BYTEA is your friend. -- Tatsuo Ishii SRA OSS, Inc. Japan ---(end of broadcas