Tom Lane <[EMAIL PROTECTED]> writes:
>> Agreed, but such corruption indicates that there is non-multibyte-safe
>> (octet-wise) case conversion somewhere, at best (with fully working
>> locale) it will cause case conversion to do nothing instead of actual
>> conversion.
>
> Yours is the first insta
Tom Lane <[EMAIL PROTECTED]> writes:
>> correct utf-8 byte sequence is 0xd18231, so it looks like we call
>> tolower() somewhere on parts of multibyte characters, and it does the
>> same as isspace() - it interprets it's argument as wide character, and
>> converts it.
>
> Indeed, and I am certainl
Victor Snezhko <[EMAIL PROTECTED]> writes:
> So, we either don't support utf-8 on BSDs
Hmm, tolower'ing octets of a multibyte string is a bug not only on
BSDs but on other architectures as well. But on BSDs it additionally
causes corruption of utf-8 data.
--
WBR, Victo
Hello,
Looks like we have more serious problem with multibyte identifiers.
When I run the following sequence of queries:
CREATE OR REPLACE FUNCTION CreateOrAlterTable()
RETURNS int
AS $$
BEGIN
if not EXISTS(SELECT relname FROM pg_class WHERE relname ILIKE 'т1' AND
relkind = 'r') then
CREA
Victor Snezhko <[EMAIL PROTECTED]> writes:
> However, in system catalogs (SELECT * FROM pg_tables WHERE
> schemaname='public') there appears to be empty strings instead
> of table names.
>
> This is on patched 8.1.4 (with ILIKE and ctype.h fixes), I'm upgrad
Tom Lane <[EMAIL PROTECTED]> writes:
>> ... I think we need convert_ident to
>> use a plpgsql_isspace() that accepts these and only these as spaces.
>> Any high-bit-set byte is part of an identifier according to scan.l's
>> rules, and convert_ident must have the same behavior regardless of locale.
Tom Lane <[EMAIL PROTECTED]> writes:
>> Hmm, there was something wrong in my utf-8 cluster setup, I
>> re-attached it and now see that isspace indeed fails:
>> LOG: plpgsql_convert_ident: ident=х, isspace array=ft, isspace(0)=f
>
> Hm. Given that we've not seen this reported elsewhere, I wonder
Victor Snezhko <[EMAIL PROTECTED]> writes:
> LOG: plpgsql_convert_ident: ident=х, isspace array=f, isspace(0)=f
> LOG: plpgsql_convert_ident: ident=test_table, isspace array=ff,
> isspace(0)=f
Hmm, there was something wrong in my utf-8 cluster setup, I
re-attached it a
Tom Lane <[EMAIL PROTECTED]> writes:
> Victor Snezhko <[EMAIL PROTECTED]> writes:
>> 2) When I try to create a stored procedure to create table (e.g., for
>>creating table only if it doesn't already exist), it fails to
>>compile if i use cyrillic
Tom Lane <[EMAIL PROTECTED]> writes:
>> Hmm, seems like plpgsql is also broken for multibyte encodings. it
>> contains some single-byte ops, like the following:
>
>> while (*s && isspace((unsigned char) *s))
>> s++;
>> if (*s++ != '.')
>> elog(ERROR, "expected d
Victor Snezhko <[EMAIL PROTECTED]> writes:
> ERROR: expected dot between identifiers: х
> CONTEXT: compile of PL/pgSQL function "createoraltertable" near line 2
>
> the following query fails:
>
> CREATE OR REPLACE FUNCTION TestFunction()
> RETURNS
Victor Snezhko <[EMAIL PROTECTED]> writes:
> 2) When I try to create a stored procedure to create table (e.g., for
>creating table only if it doesn't already exist), it fails to
>compile if i use cyrillic letter "х" (unicode id: 0x0445, utf-8
>
Volkan YAZICI <[EMAIL PROTECTED]> writes:
> On Sep 04 02:35, Tom Lane wrote:
>> "Devrim GUNDUZ" <[EMAIL PROTECTED]> writes:
>> > Like the bug report that was submitted a few days ago,
>> > http://archives.postgresql.org/pgsql-bugs/2005-09/msg00233.php
>> > I have the same thing for Turkish locale.
Jim Nasby <[EMAIL PROTECTED]> writes:
>> I'm using VB6, and trying to update a table. It is all happening on
>> my home pc with IIS running too. I can download the table to a
>> datagrid, bit I can't type any text i a textbox and update it whith
>> out the error occuring. Here [skip]
> I don't kno
Date: Sat, 03 Jun 2006 16:38:41 +0700
Hi developers,
I had to spend some time to figure out what's wrong with my data dir
because of the bug in russian translation, in src/backend/po/ru.po
Original (untranslated) message says that HAVE_INT64_TIMESTAMP differs
between postgres binaries and data
15 matches
Mail list logo
