From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Oliver Elphick <olly(at)lfix(dot)co(dot)uk> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL hackers list <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: db encoding |
Date: | 2003-10-06 20:31:24 |
Message-ID: | 2040.1065472284@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-hackers-win32 |
Oliver Elphick <olly(at)lfix(dot)co(dot)uk> writes:
> I currently use pg_encoding in Debian's automatic upgrade script to
> extract the existing default encoding from pg_database, thus:
> $ psql -q -t -d template1 -c "select encoding from pg_database where
> datname = 'template1'"
> 0
> and then I use it to translate that number into an encoding name that
> can be fed to initdb.
But you can do that with pg_encoding_to_char:
regression=# select pg_encoding_to_char(encoding) from pg_database where datname = 'template1';
pg_encoding_to_char
---------------------
SQL_ASCII
(1 row)
AFAICS the standalone pg_encoding program is only useful if you need to
do encoding-number conversions while the postmaster is not available.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Gaetano Mendola | 2003-10-06 21:03:57 | Re: psql italian translation |
Previous Message | Joshua D. Drake | 2003-10-06 20:21:59 | CREATE USER bug |
From | Date | Subject | |
---|---|---|---|
Next Message | Oliver Elphick | 2003-10-06 21:05:13 | Re: db encoding |
Previous Message | Andrew Dunstan | 2003-10-06 19:51:59 | Re: db encoding |