Re: db encoding

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Postgresql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: db encoding
Date: 2003-10-06 19:51:59
Message-ID: 3F81C7DF.6070401@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-hackers-win32

Oliver Elphick wrote:

>On Mon, 2003-10-06 at 19:30, Peter Eisentraut wrote:
>
>
>
>>About pg_encoding. There is currently no way to tell whether an encoding
>>exists. Normally you would put this kind of thing into a system table,
>>but doing that is a bit tricky with the encodings. I would like to see
>>pg_encoding go, so let's hear what information people need and give them a
>>direct way to access it.
>>
>>
>
>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.
>
>However, on looking at this, I can see that I don't need it, since I can
>just as well do
>
>$ psql -l | grep template1 | awk '{print $5}'
>SQL_ASCII
>
>so as to achieve the same result with only a single command.
>
>Therefore, you don't need to keep pg_encoding for my (the Debian
>package's) sake.
>
>
>
or save yourself a grep with this :-)

psql -l | awk '/template1/ { print $5 }'

Anyway, it looks like maybe we can get rid of pg_id and pg_encoding
after all.

cheers

andrew

(previous fan of the useless use of cat awards).

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2003-10-06 20:21:59 CREATE USER bug
Previous Message Oliver Elphick 2003-10-06 19:42:27 Re: db encoding

Browse pgsql-hackers-win32 by date

  From Date Subject
Next Message Tom Lane 2003-10-06 20:31:24 Re: db encoding
Previous Message Oliver Elphick 2003-10-06 19:42:27 Re: db encoding