Re: Sorting Problem - Mailing list pgsql-general

Agreement about what,
necessity of collate per table and Unicode build in data type, hail
yeah...
but that's really change nothing unless I get big shovel and start
"digging on" by my own
producing in reasonable period of time something...
and even for that, nobody guarantee that my exercise will be even
considered by core team...
So guess not really an answer


-----Original Message-----
From: Dennis Gearon [mailto:gearond@cvc.net]
Sent: Wednesday, August 13, 2003 11:00 AM
To: Maksim Likharev
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Sorting Problem


total agreement, ?????? (Maksim).

Maksim Likharev wrote:

> Not only SQL Server has all those possible cases for collate,
> but it does work very well.
>
> Assigning collate/encoding per column probably too much ( I never used
> it in my life )
> but assigning collate/encoding per table very much helpful.
>
> Case insensitive collation another very useful thing, which is on by
> default ( in SQL Server )
> and I really missing it in postgres, although I might probably initdb
> with some wacky
> case insensitive collate but that's more theoretical then practical.
>
> And of cause on top of that, ability to store UTF-16 data in a column
(
> build in data type )
> independent of db collate would be priceless which SQL Server allow to
> do.
> Not much of dithyrambs for SQL Server but rather reality.
>
> Thanks.
>
> -----Original Message-----
> From: Stephan Szabo [mailto:sszabo@megazone.bigpanda.com]
> Sent: Wednesday, August 13, 2003 9:32 AM
> To: Dennis Gearon
> Cc: Dennis Björklund; Maksim Likharev; pgsql-general@postgresql.org
> Subject: Re: [GENERAL] Sorting Problem
>
>
>
> On Wed, 13 Aug 2003, Dennis Gearon wrote:
>
>
>>Dennis Björklund wrote:
>>
>>
>>>In the future we need indexes that depend on the locale (and a lot
>
> of other changes).
>
>>I agree. I've been looking at the web on this subject a lot lately. I
>>am **NOT** a microslop fan, but SQL-SERVER even lets a user define a
>>language(maybe encoding) down to the column level!
>>
>>I've been reading on GNU-C and on languages, encoding, and
>
> localization.
>
>>
>
http://pauillac.inria.fr/~lang/hotlist/free/licence/fsf96/drepper/paper-
> 1.html
>
>
http://h21007.www2.hp.com/dspp/tech/tech_TechSingleTipDetailPage_IDX/1,2
> 366,1222,00.html
>
>>
>>There are three basic approaches to doing different langauges in
>
> computerized text:
>
>>    A/ various adaptations of the 8 bit character set, I.E. the
>
> ISO-8859-x series.
>
>>    B/ wide characters
>>    ********This should be how Postgress stores data
>
> internally.********
>
>>    C/ Multibyte characters
>>    ********This is how Postgress should default to sending data OUT
>
> of the application,
>
>>            i.e. to the display or the web, or other system
>
> applications********
>
> SQL has a system for defining character set specifications, collations
> and
> such (per column/literal in some cases).  We should probably look at
it
> before making decisions on how to do things.
>
>
> ---------------------------(end of
broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if
your
>       joining column's datatypes do not match
>