Hi Andreas.
----- Original Message -----
From: "Andreas Pflug" <Andreas.Pflug@web.de>
To: <pgadmin-hackers@postgresql.org>
Sent: Tuesday, June 10, 2003 5:45 PM
Subject: [pgadmin-hackers] [Fwd: pgadmin3 clientencoding]
> The current implementation of client encoding selection seems not
> satisfying to me, but since I haven't worked with client encoding so far
> I'm not sure and thus I'm asking you.
>
> Currently, the client encoding can be selected using the "Options"
> dialog, and will be active for the *next* connection established; either
> a server freshly connected using the tree or a SQL Window of View Data.
> This probably is not what the user expects; instead he'd wish to have it
> active *immediately*.
Yes, it is moving very well.
(But, it is local-code of Windows.)
>
> Additionally, I wonder if there's an individual client encoding
> necessary for tree display; I believe it's sufficient for it to be
> Unicode to support all possible encodings. Think of a situation where
> one SQL_ASCII and one EUC_JP database are residing on the same server.
> Because there's no way to convert back and forth, it's not possible to
> display the second database if the first is retrieved using its native
> encoding.
>
>
> Do we really need special encodings, besides unicode? If so, this should
> be implemented on a tree node (Server property: client encoding) to make
> it possible to let the change of encoding have immediate effect, or as
> the "System Object" setting is implemented.
>
> Regards,
> Andreas
As for me, it doesn't examine present UNICODE complying with that it can be
said that it is certain.
(It doesn't seem to go well though a movement is still being watched.)
UNICODE which is one of Clientencodings..
Is it injustice?
With kindest regards,
Hiroshi-Saito
