Skip site navigation (1) Skip section navigation (2)

Re: String encoding during connection "handshake"

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: sulfinu(at)gmail(dot)com
Cc: Usama Munir <usama(dot)munir(at)enterprisedb(dot)com>,pgsql-hackers(at)postgresql(dot)org
Subject: Re: String encoding during connection "handshake"
Date: 2007-11-28 16:40:30
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Wed, Nov 28, 2007 at 05:54:05PM +0200, sulfinu(at)gmail(dot)com wrote:
> Regarding the problem of "One True Encoding", the answer seems obvious to me: 
> use only one encoding per database cluster, either UTF-8 or UTF-16 or another 
> Unicode-aware scheme, whichever yields a statistically smaller database for 
> the languages employed by the users in their data. This encoding should be a 
> one time choice! De facto, this is already happening now, because one cannot 
> change collation rules after a cluster has been created.

Umm, each database in a cluster can have a different encoding, so there
is no such thing as the "cluster's encoding". You can certainly argue
that it should be a one time choice, but I doubt you'll get people to
remove the possibilites we have now. If fact, if anything we'd probably
go the otherway, allow you to select the collation on a per
database/table/column level (SQL complaince requires this).

This has nothing to do with C by the way. C has many features that
allow you to work with different encodings. It just doesn't force you
to use any particular one.

Have a nice day,
Martijn van Oosterhout   <kleptog(at)svana(dot)org>
> Those who make peaceful revolution impossible will make violent revolution inevitable.
>  -- John F Kennedy

In response to


pgsql-hackers by date

Next:From: Dave PageDate: 2007-11-28 16:53:43
Subject: Re: [HACKERS] Time to update list of contributors
Previous:From: Joshua D. DrakeDate: 2007-11-28 16:32:43
Subject: Re: [HACKERS] Time to update list of contributors

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group