Re: 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(at)megazone(dot)bigpanda(dot)com]
> Sent: Wednesday, August 13, 2003 9:32 AM
> To: Dennis Gearon
> Cc: Dennis Björklund; Maksim Likharev; pgsql-general(at)postgresql(dot)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
>