Thread: [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*. 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
> -----Original Message----- > From: Andreas Pflug [mailto:Andreas.Pflug@web.de] > Sent: 10 June 2003 09:46 > To: pgadmin-hackers@postgresql.org > Subject: [pgadmin-hackers] [Fwd: pgadmin3 clientencoding] > > 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. Hmm, good point. Perhaps we should just say Unicode all the time then when we have a Unicode build. > > 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. No, because then you are mixing schema with commands that may affect the schema in non-obvious ways. Regards, Dave.
On Tuesday 10 June 2003 12:10, you wrote: > Hmm, good point. Perhaps we should just say Unicode all the time then > when we have a Unicode build. + We need to check the conversion safety of data entered by users. Cheers, Jean-Michel
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