Skip site navigation (1) Skip section navigation (2)

Database->ServerEncoding, ClientEncoding

From: Jean-Michel POURE <jm(dot)poure(at)freesurf(dot)fr>
To: Dave Page <dpage(at)vale-housing(dot)co(dot)uk>
Cc: pgadmin-hackers(at)postgresql(dot)org
Subject: Database->ServerEncoding, ClientEncoding
Date: 2002-02-25 17:12:52
Message-ID: 200202251712.g1PHCqLx004119@www1.translationforge (view raw, whole thread or download thread mbox)
Lists: pgadmin-hackers
Hi Dave,

I used pgSchema today with a Latin1 encoding hack.

Whenever a character does not exist in Latin1 (example : euro sign), an error 
is returned. Obviously, this is not always the case: Japanese is transformed 
in unreadable characters without error.

My impression is that client encoding is not ***very** secure. A full unicode 
chain is a better solution. But we need Client encoding support as it offers 
a wide variety of encodings ... and is compatible with VB.

Maybe we could start modifying pgSchema->Databases and pgSchema->pgDatabase. 
What would you think if we :
- renamed EncodingName into ServerEncoding,
- added ClientEncoding.

Then, in frmSQLInput, we would add a combo to choose the encoding needed.

This will allow me to view UTF-8 data in Latin1 and export it in UTF-8. Isn't 
it marvelous?


In response to


pgadmin-hackers by date

Next:From: Jean-Michel POUREDate: 2002-02-25 17:20:18
Subject: Re: pgAdmin2 Japanese display
Previous:From: Hiroshi InoueDate: 2002-02-25 16:19:19
Subject: Re: pgAdmin2 Japanese display

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group