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

Re: Database->ServerEncoding, ClientEncoding

From: Dave Page <dpage(at)vale-housing(dot)co(dot)uk>
To: "'jm(dot)poure(at)freesurf(dot)fr'" <jm(dot)poure(at)freesurf(dot)fr>,pgadmin-hackers(at)postgresql(dot)org
Subject: Re: Database->ServerEncoding, ClientEncoding
Date: 2002-02-26 11:20:51
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgadmin-hackers

> -----Original Message-----
> From: Jean-Michel POURE [mailto:jm(dot)poure(at)freesurf(dot)fr] 
> Sent: 26 February 2002 10:54
> To: pgadmin-hackers(at)postgresql(dot)org
> Subject: Re: [pgadmin-hackers] Database->ServerEncoding, 
> ClientEncoding
> Le Mardi 26 Février 2002 11:21, Dave Page a écrit :
> > Do we set system encoding per database, or per server.
> > Where do we set it?
> > How do we set it?
> Yesterday, tried a hack in SQLExecute, applying 
> CLIENT_ENCODING on the fly at 
> the beginning of each SQL query. There does not seem to be a 
> real overhead.

Sounds a little messy to me, and will certainly clutter up logs and things.

> > Do we set user/data encoding per database or per server
> > Where do we set it (bear in mind that there is no SQLInput 
> form if the 
> > user does a 'View Data')? How do we set it?
> It would be better if we could set it per database (?) in 
> pgDatabase->DataEncoding and pgDatabase->SystemEncoding.

Yes, I think I agree.

> In SQLInput, if a user does not choose a special encoding, we apply 
> pgDatabase->DataEncoding as default.

I think the neatest place to set these will be in frmDatabase. Doing it
elsewhere will just be confusing. For most users, they can just leave them
alone, someone like yourself can just set & forget.

This would have to be stored in the registry - HKCU\Software\pgAdmin
II\Encodings\>Connection ID>\<Database Name>\[DataEncoding | systemEncoding]
- where <Connection ID> is of the form user|server|port as we using in the
Connections MRU list.

So, when a database is first connected, we read the relevant value and issue
a SET CLIENT_ENCODING. If pgDatabase->SystemEncoding gets updated, we write
to the registry, and issue another SET CLIENT_ENC...

That will work for System stuff. On the User/Data side, those queries *only*
come from frmSQLInput or a 'View Data' (iirc). For these types of query,
*if* we had a second connection to the database, then it could maintain it's
client encoding neatly as well. This would also have the advantage that
large queries would not be using the system connections and could
effectively give us a 'threaded' effect.

The downside would be that we would have extra connections (potentially
double). This could be minimised by only connecting on first use.


Regards, Dave.


pgadmin-hackers by date

Next:From: Dave PageDate: 2002-02-26 11:27:35
Subject: Re: Locale, Encoding
Previous:From: Jean-Michel POUREDate: 2002-02-26 11:00:42
Subject: Locale, Encoding

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