Message-ID: <4D85AEC4.1010703@enterprisedb.com>
Date: Sun, 20 Mar 2011 09:37:40 +0200
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; fi-FI;
	rv:1.9.1.16) Gecko/20101226 Icedove/3.0.11
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: pgsql-docs@postgreSQL.org
Subject: Re: Ordering of sections in chapter 22 (Localization)
References: <16750.1300604795@sss.pgh.pa.us>
In-Reply-To: <16750.1300604795@sss.pgh.pa.us>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 20.03.2011 09:06, Tom Lane wrote:
> I'm wondering why chapter 22 discusses locales (and now collations)
> before encodings.  ISTM the logical order is the reverse, because
> encodings can be explained without reference to locales, but it's very
> difficult to cover locales without touching on encodings.  There are a
> lot of forward references in sections 22.1 and 22.2 as it stands.
> So I'd like to flip this around --- any objections?

I only see these two forward references:

In 22.1.1:
> If more than one character set can be used for a locale then the specifications can take the form language_territory.codeset. For example, fr_BE.UTF-8 represents the French language (fr) as spoken in Belgium (BE), with a UTF-8 character set encoding.

In 22.2.2:
> Also, a collation is tied to a character set encoding (see Section 22.3). The same collation name may exist for different encodings.

To me, it feels natural to discuss locales and collations first. They 
are a higher level feature, they affect query results and there's new 
syntax for collations. Encoding is just an implementation detail, you 
just have to set client and server encodings correctly to match your 
locale and the OS or application.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com