On 05/21/2013 05:50 AM, Christoph Berg wrote:
> Not sure if that's enough and we don't need to look at the encoding or
> lc_* values too. Possibly we could into the cluster created to figure
> out the values (postgresql.conf maybe?).
I guess it depends on what you intend to display there. Thinking of
pg_createcluster as a simple wrapper around initdb, I made it fit what's
getting passed to initdb. In turn, trusting that to do the Right Thing
(tm) - i.e. use a specific locale when explicitly given one. Or complain
if locale and encoding don't match. Or if it's given nonsense entirely,
i.e.:
> # ./pg_createcluster --locale foo_BAR 9.2 baz
> Creating new cluster 9.2/baz ...
> config /etc/postgresql/9.2/baz
> data /var/lib/postgresql/9.2/baz
> locale foo_BAR (custom)
> initdb: invalid locale name "foo_BAR"
> initdb: invalid locale name "foo_BAR"
> initdb: invalid locale name "foo_BAR"
> initdb: invalid locale name "foo_BAR"
> initdb: invalid locale name "foo_BAR"
> initdb: invalid locale name "foo_BAR"
> port 5435
However, it's worth noting that initdb itself is more verbose, i.e.:
> # /usr/lib/postgresql/9.2/bin/initdb -D /tmp/testdb --locale de_CH.ISO-8859-1 --encoding Latin-1 --lc-monetary
de_DE.UTF-8
> The files belonging to this database system will be owned by user "postgres".
> This user must also own the server process.
>
> The database cluster will be initialized with locales
> COLLATE: de_CH.ISO-8859-1
> CTYPE: de_CH.ISO-8859-1
> MESSAGES: de_CH.ISO-8859-1
> MONETARY: de_DE.UTF-8
> NUMERIC: de_CH.ISO-8859-1
> TIME: de_CH.ISO-8859-1
> The default text search configuration will be set to "german".
> ...
vs:
> # pg_createcluster --locale de_CH --encoding Latin-1 --lc-monetary de_DE.UTF-8 9.2 foo
> Creating new cluster 9.2/foo ...
> config /etc/postgresql/9.2/foo
> data /var/lib/postgresql/9.2/foo
> locale de_CH
> port 5435
initdb emits useful information that pg_createcluster shouldn't hide,
IMO. Especially in case the user manually specifies locale(s) and/or
encoding.
Of course, we could try to figure this out after the fact. However,
initdb itself reporting what it uses seems the most reliable to me.
While I see little use and justification in cross-checking initdb.
Regards
Markus Wanner
