> -Original Message-
> From: Jean-Michel POURE [mailto:[EMAIL PROTECTED]]
> Sent: 26 February 2002 12:09
> To: [EMAIL PROTECTED]
> Subject: Re: [pgadmin-hackers] Database->ServerEncoding,
> ClientEncoding
>
>
> Le Mardi 26 Février 2002 12:20, Dave Pag
Le Mardi 26 Février 2002 12:20, Dave Page a écrit :
> 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 enco
> -Original Message-
> From: Jean-Michel POURE [mailto:[EMAIL PROTECTED]]
> Sent: 26 February 2002 10:54
> To: [EMAIL PROTECTED]
> Subject: Re: [pgadmin-hackers] Database->ServerEncoding,
> ClientEncoding
>
>
> Le Mardi 26 Février 2002 11:21, Dave Page
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 o
> -Original Message-
> From: Jean-Michel POURE [mailto:[EMAIL PROTECTED]]
> Sent: 26 February 2002 09:44
> To: [EMAIL PROTECTED]
> Subject: Re: [pgadmin-hackers] Database->ServerEncoding,
> ClientEncoding
>
>
> > ServerEncodingID (Long)
> >
> ServerEncodingID (Long)
> ServerEncodingName (String)
I still wonder why ServerEncodingID is needed. It adds complexity to pgSchema
without beeing used. Can't ServerEncodingID be masked?
> ClientEncodingID (Long)
> The ClientEncodingID would be the Windows LCID (I assume that's relevant
> in
Le Mardi 26 Février 2002 09:46, Dave Page a écrit :
> 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
> -Original Message-
> From: Jean-Michel POURE [mailto:[EMAIL PROTECTED]]
> Sent: 25 February 2002 21:07
> To: Dave Page
> Cc: [EMAIL PROTECTED]
> Subject: Re: [pgadmin-hackers] Database->ServerEncoding,
> ClientEncoding
>
>
> Hi Dave,
>
> 1)
Le Lundi 25 Février 2002 21:30, Dave Page a écrit :
> 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.
> The only other option I can think of, would be to open a dedicated
> connection for eac
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)
> SystemEncodingNam
Jean-Michel POURE allegedly said:
> Hi Dave,
>
> Also, we need to set Schema->Encoding. This is to define what client
> encoding is used for schema creation. For example, I would like to use
> Latin1 for writing functions.
As I said in my previous message, we can only set it once for each
datab
Jean-Michel POURE allegedly said:
> 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
Hi Dave,
Also, we need to set Schema->Encoding. This is to define what client encoding
is used for schema creation. For example, I would like to use Latin1 for
writing functions.
Cheers,
Jean-Michel
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
14 matches
Mail list logo
