Thread: Client Encoding
It seems we all seem to think that client_encoding should be set to UNICODE in all cases for unicode builds and SQL_ASCII for others, therefore I've backed out the previous changes and implemented this behaviour instead. Any problems, please let me know. Regards, Dave
Hi Dave. They are still imperfect. This binary understands SJIS-code more securely than UNICODE now. http://cre-ent.skcapi.co.jp/~saito/pgadmin/lib/pgadmin3_2003-06-10_bin.zip Of course, other encodings are understood, too. Leave it because it is input and output of the local data and it doesn't become a difficulty. With kindest regards, Hiroshi-Saito ----- Original Message ----- From: "Dave Page" <dpage@vale-housing.co.uk> To: <pgadmin-hackers@postgresql.org> Sent: Tuesday, June 10, 2003 10:43 PM Subject: [pgadmin-hackers] Client Encoding It seems we all seem to think that client_encoding should be set to UNICODE in all cases for unicode builds and SQL_ASCII for others, therefore I've backed out the previous changes and implemented this behaviour instead. Any problems, please let me know. Regards, Dave
Dave Page wrote: >It seems we all seem to think that client_encoding should be set to >UNICODE in all cases for unicode builds and SQL_ASCII for others, >therefore I've backed out the previous changes and implemented this >behaviour instead. > Looks good to me. I've changed libpq handling so utf-8 is correctly converted to utf-16. I believe encoding is now handled correctly for unicode builds. A current win32 build is uploaded to snake.pgadmin.org. Client encoding setting might still be useful for non-unicode builds, if we want to support them at all. The list of selectable client encodings would have to be restricted to 8-bit/char codes. Actually, I'd prefer to recommend unicode-builds as *the* one and only solution for multi-encoding environments, leaving the non-unicode build pinned to sql_ascii. Regards, Andreas
> -----Original Message----- > From: Andreas Pflug [mailto:Andreas.Pflug@web.de] > Sent: 11 June 2003 13:52 > To: pgadmin-hackers@postgresql.org; Jean-Michel POURE; Dave Page > Subject: Re: [pgadmin-hackers] Client Encoding > > > Dave Page wrote: > > >It seems we all seem to think that client_encoding should be set to > >UNICODE in all cases for unicode builds and SQL_ASCII for others, > >therefore I've backed out the previous changes and implemented this > >behaviour instead. > > > Looks good to me. > > I've changed libpq handling so utf-8 is correctly converted > to utf-16. I > believe encoding is now handled correctly for unicode builds. > A current > win32 build is uploaded to snake.pgadmin.org. > > Client encoding setting might still be useful for non-unicode > builds, if > we want to support them at all. The list of selectable client > encodings > would have to be restricted to 8-bit/char codes. > Actually, I'd prefer to recommend unicode-builds as *the* one > and only > solution for multi-encoding environments, leaving the > non-unicode build > pinned to sql_ascii. Sounds good. They only problem with Unicode builds will (==should) be Win9x... Regards, Dave.
Dave Page wrote: >Sounds good. They only problem with Unicode builds will (==should) be >Win9x... > > I don't believe Win9x is a preferred administrator's os... :-> Let's wait and see if there are really many people trying to run pgAdmin3 under these ancient os. Regards, Andreas
> -----Original Message----- > From: Andreas Pflug [mailto:Andreas.Pflug@web.de] > Sent: 11 June 2003 14:30 > To: Dave Page; pgadmin-hackers@postgresql.org > Subject: Re: [pgadmin-hackers] Client Encoding > > > Dave Page wrote: > > >Sounds good. They only problem with Unicode builds will > (==should) be > >Win9x... > > > > > I don't believe Win9x is a preferred administrator's os... :-> Let's > wait and see if there are really many people trying to run pgAdmin3 > under these ancient os. Oh there are a few :-( They crop up on the Cygwin list periodically. Regards, Dave.