Re: Sorting Problem - Mailing list pgsql-general

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
>