Re: SQL ASCII encoding

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Frank Church <pgsql(at)adontendev(dot)net>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: SQL ASCII encoding
Date: 2006-04-05 13:54:19
Message-ID: 20060405135419.GD18401@svana.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, Apr 05, 2006 at 01:35:00PM +0000, Frank Church wrote:
>
> My databases are created in SQL ASCII by default.
>
> Is there some disadvantage to this? As a British user, which is the preferred
> character set and what advantage do I have to gain by using it?database

SQL ASCII just means that the database will not do anything encoding
related for you. It won't check it nor will it convert anything.

The downside is that your apps could be uploading UTF-8, Latin-1,
Latin-9, anything and there will be no way to tell the difference. Also
things like upper(), lower() and case-comparison won't work on anything
other than ASCII characters.

If you setup your database to be UNICODE/UTF-8 then postgres can check
that the stuff you send is properly encoded. In your clients you should
do something like "set client_encoding=latin9" to ensure everything
gets converted up.

As a british user, latin9 will cover most of your needs, unless
ofcourse someone wants to enter their name in chinese :)

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2006-04-05 14:03:06 Re: pg_dump and copy command
Previous Message Jonathan Beit-Aharon 2006-04-05 13:53:39 8.1.3's /etc/init.d/postgresql fails, logging "standard in must be a tty"