Last minute edit:
src/test/mb seems a little bit old. I've tested SQL files in
src/test/mb/sql with the expected results in src/test/mb/expected
manually and it worked. (Output files need a little bit editing, like
removing lines similar to "CREATE TABLE".) But it'll be better if any
EUC users will
Volkan YAZICI wrote:
> On 12/1/05, Bruce Momjian wrote:
> > Where are we on this patch? Is it to be applied?
>
> After Tom's advice (he was doubtful about the patch), while I was
> thinking about how to improve the spectrum of tests, decided to use
> src/test/mb. In the tests, patch just succeded
On 12/1/05, Bruce Momjian wrote:
> Where are we on this patch? Is it to be applied?
After Tom's advice (he was doubtful about the patch), while I was
thinking about how to improve the spectrum of tests, decided to use
src/test/mb. In the tests, patch just succeded for unicode and failed
on big5,
Hi,
On Thu, 1 Dec 2005, Bruce Momjian wrote:
Where are we on this patch? Is it to be applied?
The patch worked on FreeBSD 5.4-CURRENT. Maybe what Tom wants is more port
reports, hmm?
Volkan stated out the reasons that why we need this patch, I'll not repeat
it again.
Regards,
--
Devr
Where are we on this patch? Is it to be applied?
---
Volkan YAZICI wrote:
> On 11/27/05, Volkan YAZICI <[EMAIL PROTECTED]> wrote:
> > Tests made on an i686 with a
> > 2.6.12.5 kernel. Here's a short list of cases I tried w
On 11/27/05, Volkan YAZICI <[EMAIL PROTECTED]> wrote:
> Tests made on an i686 with a
> 2.6.12.5 kernel. Here's a short list of cases I tried with both latin5
> and unicode charsets:
> - lower/upper functions with Turkish characters.
> - ILIKE matches with both lower and upper case Turkish character
On 11/27/05, Tom Lane <[EMAIL PROTECTED]> wrote:
> > Yes, indeed. I agree with you to find a proper solution for character
> > set handling. But, IMHO, it's better to have a-patchy working system
> > instead of a not working one.
>
> But you just agreed that it doesn't work.
You get me wrong. I tr
Volkan YAZICI <[EMAIL PROTECTED]> writes:
> On 11/27/05, Tom Lane <[EMAIL PROTECTED]> wrote:
>> The really fundamental problem is that tolower/toupper don't work
>> on wchar_t.
> Yes, indeed. I agree with you to find a proper solution for character
> set handling. But, IMHO, it's better to have a-
On 11/27/05, Tom Lane <[EMAIL PROTECTED]> wrote:
> Doesn't this just move the failure cases around?
I don't think so. I've tried to fix every tolower/toupper related
problem (depending on the MB characters) I found in the code. If
there's still a problem with them, it should be related with the
pg
[Sorry if the post is duplicated. But I don't receive and ACK from majordamo.]
On 11/27/05, Tom Lane <[EMAIL PROTECTED]> wrote:
> Doesn't this just move the failure cases around?
I don't think so. I've tried to fix every tolower/toupper related
problem (depending on the MB characters) I found in
Volkan YAZICI <[EMAIL PROTECTED]> writes:
> Here's small patch to fix case conversion problems for ILIKE and
> (Oracle Compat.) lower/upper functions. (Related bug report is here:
> http://archives.postgresql.org/pgsql-bugs/2005-10/msg1.php)
Doesn't this just move the failure cases around?
Th
Last minute edit:
On 11/26/05, Volkan YAZICI <[EMAIL PROTECTED]> wrote:
- In tests it succeeded for Turkish characters while using LATIN5
- encoding. But when encoding is UNICODE it still doesn't work. (IMHO,
- for latin-N encodings there will be no compatibility problems; for
- Unicode, I've no i
Here's small patch to fix case conversion problems for ILIKE and
(Oracle Compat.) lower/upper functions. (Related bug report is here:
http://archives.postgresql.org/pgsql-bugs/2005-10/msg1.php)
In tests it succeeded for Turkish characters while using LATIN5
encoding. But when encoding is UNICO
13 matches
Mail list logo
