Re: db encoding
От | Andrew Dunstan |
---|---|
Тема | Re: db encoding |
Дата | |
Msg-id | 3F81C7DF.6070401@dunslane.net обсуждение исходный текст |
Ответ на | Re: db encoding (Oliver Elphick <olly@lfix.co.uk>) |
Список | pgsql-hackers |
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).
В списке pgsql-hackers по дате отправления: