Thread: encoding???

encoding???

From
Carol Walter
Date:
Greetings...

I'm really confused about something.  I hope you'll help.  I have a
client who wants to use Asian Character data.  The database he wants
to use is set to SQL_ASCII, the default.  I thought there might be an
ALTER DATABASE command that would change this, but I've been through
the documentation and it says that encoding is done at the client
level and is changed with a set statement.  I assumed that would be
like setting the search path so I tried it and I was able to set the
encoding for my session to UTF8.  I guess my question is how does
this work, where the database is set to use one encoding sequence and
it is set for the client session to something else.

Carol Walter


Re: encoding???

From
Hannes Dorbath
Date:
Carol Walter wrote:
> I'm really confused about something.  I hope you'll help.  I have a
> client who wants to use Asian Character data.  The database he wants to
> use is set to SQL_ASCII, the default.  I thought there might be an ALTER
> DATABASE command that would change this, but I've been through the
> documentation and it says that encoding is done at the client level and
> is changed with a set statement.  I assumed that would be like setting
> the search path so I tried it and I was able to set the encoding for my
> session to UTF8.  I guess my question is how does this work, where the
> database is set to use one encoding sequence and it is set for the
> client session to something else.

There are 3 things, cluster locale set at initdb, database encoding set
at database creation and client encoding. The client encoding can be
changed by the client at any time. PostgreSQL will translate transparent
from client to database encoding. For UTF-8, chose a UTF-8 cluster
locale and recreate the database, it will pick UTF-8 for the database by
default now.


--
Best regards,
Hannes Dorbath

Re: encoding???

From
Ivo Rossacher
Date:
SQL_ASCII is not really an encoding, it is more the lack of any encoding
support from the server. With this setting the encoding is fully the
responsibility of the client application.
This is very comfortable for special cases but for most regular cases it is
only asking for troubles.
Therfore for most cases UTF8 should be the prefered encoding on the server
side. The client encoding only tells the server how to convert the data from
and to the client. How to set this depends on the capabilities of the client.

In the manual in chapter 22.2 Character Set Support you can get more details
and all from the server supported conversions.

Best regards
Ivo

Am Dienstag, 26. Februar 2008 20.41:45 schrieb Carol Walter:
> Greetings...
>
> I'm really confused about something.  I hope you'll help.  I have a
> client who wants to use Asian Character data.  The database he wants
> to use is set to SQL_ASCII, the default.  I thought there might be an
> ALTER DATABASE command that would change this, but I've been through
> the documentation and it says that encoding is done at the client
> level and is changed with a set statement.  I assumed that would be
> like setting the search path so I tried it and I was able to set the
> encoding for my session to UTF8.  I guess my question is how does
> this work, where the database is set to use one encoding sequence and
> it is set for the client session to something else.
>
> Carol Walter
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster