Re: case insensitive sorting & searching in oracle 10g - Mailing list pgsql-general

From David Garamond
Subject Re: case insensitive sorting & searching in oracle 10g
Date
Msg-id 4113577C.6050802@zara.6.isreserved.com
Whole thread Raw
In response to case insensitive sorting & searching in oracle 10g  (David Garamond <lists@zara.6.isreserved.com>)
Responses Re: case insensitive sorting & searching in oracle 10g  (David Garamond <lists@zara.6.isreserved.com>)
List pgsql-general
Stephan Szabo wrote:
>>Could you point me where in the archives can I read more? I'm having a
>>bit of trouble finding discussion on this. Thanks.
>
> I didn't spend too much time looking, but there are a few that look like
> they'll touch upon related issues:
>
> http://archives.postgresql.org/pgsql-hackers/2003-11/msg01299.php
> http://archives.postgresql.org/pgsql-hackers/2001-11/msg00610.php
> http://archives.postgresql.org/pgsql-hackers/2002-11/msg00515.php

So, as I understand it, the current plan is:

1. charset + encoding will be tagged to each column (as per SQL standard)

2a. individual string values will be tagged with charset+encoding. this
incurs an overhead of 1-2 bytes per value.

or

2b. all string values will be stored in a single charset+encoding (e.g.
unicode + utf8). this will of course upset some people, e.g. japanese.

Is it 1+2a or 1+2b? Recent language implementations/VM like Parrot and
Ruby2 are inclined to 2a, I think.

--
dave

pgsql-general by date:

Previous
From: Gaetano Mendola
Date:
Subject: Re: getting dead locks with 2 functions
Next
From: David Garamond
Date:
Subject: Re: case insensitive sorting & searching in oracle 10g