Re: [BUGS] BUG #1931: ILIKE and LIKE fails on Turkish locale

2006-09-06 Thread Victor Snezhko 
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 int
> AS $$
> BEGIN
>   SELECT х FROM test_table;
>   RETURN 0;
> END;
> $$ LANGUAGE plpgsql;

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 dot between identifiers: %s", sstart);

If we state that there are fixes for multibyte encodings in 8.2, we
should note that plpgsql is still broken. Being unfamiliar with
postgresql multibyte internals, I don't see a simple way to fix it
now. 

-- 
WBR, Victor V. Snezhko
E-mail: [EMAIL PROTECTED]



---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [BUGS] BUG #1931: ILIKE and LIKE fails on Turkish locale

2006-09-06 Thread Tom Lane 
Victor Snezhko <[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 dot between identifiers: %s", sstart);

That code is not broken ... at least not unless isspace() is.

regards, tom lane

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [BUGS] BUG #1931: ILIKE and LIKE fails on Turkish locale

2006-09-06 Thread Victor Snezhko 
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 dot between identifiers: %s", sstart);
>
> That code is not broken ... at least not unless isspace() is.

OK, sorry for the FUD, I'm just trying to find a cause... I will not
bring such ungrounded accusations next time. 

But... maybe I misunderstand something fundamental, but should isspace
work when we pass one byte of multibyte character?

I'm digging this procedure (plpgsql_convert_ident()) and will report
if I find something wrong inside it and not inside isspace.

-- 
WBR, Victor V. Snezhko
E-mail: [EMAIL PROTECTED]



---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [BUGS] BUG #1931: ILIKE and LIKE fails on Turkish locale

2006-09-06 Thread Tom Lane 
Victor Snezhko <[EMAIL PROTECTED]> writes:
> But... maybe I misunderstand something fundamental, but should isspace
> work when we pass one byte of multibyte character?

Yes, it should, because we only allow ASCII-superset encodings inside
the backend.  That is, characters that actually occupy multiple bytes
must have the high bit set in each such byte, and we expect that
isspace, isdigit, etc will not return true for any such byte.

regards, tom lane

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings