Re: Database->ServerEncoding, ClientEncoding

> -----Original Message-----
> From: Jean-Michel POURE [mailto:jm.poure@freesurf.fr]
> Sent: 25 February 2002 21:07
> To: Dave Page
> Cc: pgadmin-hackers@postgresql.org
> Subject: Re: [pgadmin-hackers] Database->ServerEncoding,
> ClientEncoding
>
>
> Hi Dave,
>
> 1) We need two client encodings :
> - one for querying system object,
> - another for displaying data.
>
> > DataEncodingID (Long)
> > DataEncodingName (String)
> The encoding used to display data.
> In my example, UTF-8 to export data, Latin1 otherwize.
>
> > SystemEncodingID (Long)
> > SystemEncodingName (String)
> The encoding used to program schema objects, in my case
> Latin1. "System" because this term is used in pgServerExecSQL.
>
> Example : my database is UTF-8:
> - Latin1 objects,
> - Japanese data.
>
> 2) I hacked pgServerExecSQL like this :
> >As I said in my previous message, we can only set it once for each
> database, otherwise it will become unpredictable as you jump
> from window to window.
>
>   'Get the Query Type and set client encoding
>   szClientEncoding = "SQL_ASCII"
>   SQL_Encoding = ""
>
>   If (QryType And qrySystem) = qrySystem Then
>     szQueryType = "System"
>     szClientEncoding =
> objServer.Databases(Database).SystemEncodingName
>   ElseIf (QryType And qryData) = qryData Then
>     szQueryType = "Data"
>     szClientEncoding = objServer.Databases(Database).DataEncodingName
>   ElseIf (QryType And qryUser) = qryUser Then
>     szQueryType = "User"
>     szClientEncoding = "SQL_ASCII"
>   End If
>
>   If szClientEncoding <> "" Then
>     SQL_Encoding = "SET CLIENT_ENCODING = '" &
> szClientEncoding & "'; "
>   End If
>
>   RaiseEvent SQLExecute(SQL, Connection)
>   objServer.iLogEvent "SQL (" &
> GetDatabase(Connection.ConnectionString) &
> "): " & SQL, etSQL
>   Set ExecSQL = Connection.Execute(SQL_Encoding & SQL)
>
> What do you think?

I forgot I added the query types (that was a recent change to support the
session recorder). Something like that will probably do it, yes. From a
sensible user interface point of view, you could select the system encoding
when logging on (that would be server-wide - would that be a problem), and
the data/user encoding from the SQL window, but default to the system
encoding if a different selection has never been made.

Thoughts?

/D