[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Postgres 8.4.4-1 (Enterprise db) problems -- system hosed?
Date: Thu, 1 Jul 2010 22:07:35 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

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

> 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_UID=503
> SSH_AUTH_SOCK=/tmp/launch-dt8zMb/Listeners
> 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.

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

[Prev in Thread] Current Thread [Next in Thread]