Re: [Gnumed-devel] Postgres 8.4.4-1 (Enterprise db) problems -- system hosed?

[Karsten Hilbert]

On Thu, Jul 01, 2010 at 12:13:09PM -0700, Jim Busser wrote:

> >> en_CA
> >>    --> client_encoding = UNICODE (I think)
> 
> correction: I think I misread the bootstrapper log. The file
> 
>       Postgresql.conf
> 
> comments -out (#) the setting client_encoding, in fact it says
> 
> #client_encoding = sql_ascii          # actually, defaults to database        
>                                       # encoding

Well, that's just a setting and won't change reality. I can
set Klingon encoding for that matter and still have utf8 if
it IS utf8.

> > That should'a worked as well, maybe we can improve the test
> > as Sebastian suggested:
> > 
> >             # verify encoding
> 
> so given what was returned by (system user postgres calling)
> 
>       psql -l
> 
> can the bootstrapper be improved to recognize that UTF8 is in fact available?

I already did (see my post this afternoon) - the
bootstrapper now asks PostgreSQL what the server_encoding is
if LC_CTYPE does not seem suitable.

I'm starting to think it should perhaps *only* ask and not
look at LC_CTYPE anymore. But we'll leave that for later -
at which time we'll heed Dave's advice of dealing with
per-database encodings which functionality starts becoming
available.

> On my Mac, the result of the bash "env" command is
> ************************************
> (for user postgres) i
> 
> bash-3.2$ env
> SHELL=/bin/bash
> TERM=xterm-color
> USER=postgres
> SUDO_USER=djb
> SUDO_UID=503
> SSH_AUTH_SOCK=/tmp/launch-dt8zMb/Listeners
> __CF_USER_TEXT_ENCODING=0x0:0:0
> USERNAME=root
> PATH=/Library/PostgreSQL/8.4/bin:opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/Library/Frameworks/Python.framework/Versions/Current/bin:/bin:/sbin:/usr/bin:/usr/local/bin:/usr/sbin
> PWD=/
> EDITOR=/usr/bin/edit
> LANG=en_CA.UTF-8

That is a "proper" (as in fully specified) locale setting
(despite it using a funny (though documented) variable).

While thank's for providing the environment listing (which
surely seems to indicate UTF8 is thought to work) this only
shows a wish by the respective user towards the system to
activate that encoding.

Which is a rather longwinded way of saying that the
environment isn't the place to look ;-)

Rather it's preferable to ask the server what encoding it is
*in*. Which we now do.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346