Committed.
Tom Lane wrote:
> * You should try to get rid of LOCALE_NAME_BUFLEN altogether. Definitely
> the comment about it in pg_control.h is now obsolete.
Yep. I removed LOCALE_NAME_BUFLEN. The real max length of a locale name
is now NAMEDATALEN, because it's stored in a name field in pg_database.
NAMEDATALEN is only 64 bytes, whereas LOCALE_NAME_BUFLEN was 128. 64
bytes should be enough for "en_GB.UTF8" style locale names, but I wonder
if it's enough for the longer names used on Windows? Could someone
confirm that, please?
> An important restriction, however, is that each database's character set
> must be compatible with the database's <envar>LC_CTYPE</> setting.
>
> Also I wonder whether we shouldn't say that it must be compatible with
> LC_CTYPE *and* LC_COLLATE.
I think we should, but that's in fact not what is tested. Before the
patch as well, we only tested that the encoding matches LC_CTYPE, but
you could set LC_COLLATE to anything. I'll work on a subsequent patch to
tighten that.
> * This makes sense, but then shouldn't we make the identical restriction
> for encoding?
>
> + The <literal>COLLATE</> and <literal>CTYPE</> settings must match
> + those of the template database, except when template0 is used as
> + template. This is because <literal>COLLATE</> and <literal>CTYPE</>
It wouldn't be as bullet-proof for encoding, because we'd still have the
problem that the encoding in the shared system tables would be
ill-defined. That's a pre-existing problem, though. We could simply
remove support for per-database encodings altogether and fix it at
initdb time, as Martijn suggest earlier, but now that we have
per-database locales, per-database encodings is a lot more useful as well.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com