Hi Andreas. ----- Original Message ----- From: "Andreas Pflug" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
