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
Jean-Michel POURE allegedly said:
> Le Lundi 25 Février 2002 17:19, Hiroshi Inoue a écrit :
>> SET CLIENT_ENCODING to 'SJIS'
>> Strictly speaking, you need a multibyte psqlodbc driver
>> to handle SJIS(Shift Jis) properly.
>
> 2) Is the multibyte psqlodbc driver a separate driver? What are the
> s
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
Le Lundi 25 Février 2002 17:19, Hiroshi Inoue a écrit :
> SET CLIENT_ENCODING to 'SJIS'
> Strictly speaking, you need a multibyte psqlodbc driver
> to handle SJIS(Shift Jis) properly.
Dear Hiroshi,
Thank you for your answer. Could you tell us more about SJIS:
1) Is it Microsoft encoding standard
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
Hi Jean-Michel,
I just comitted the following changes to pgSchema:
Invalidate Caches before refreshing hierarchy in pgSchema.
Standardised db name access method throughout pgSchema's classes, and added
caching.
This update touched virtually all classes and is quite large, but shouldn't
affect
Le Lundi 25 Février 2002 12:33, Dave Page a écrit :
> Yes, but my point is that setting the client encoding on the server worked
> for latin, so would the same work for EUC_JP? Following other emails
> though, I assume not because the PCs are already in latin1 and that is the
> big difference?
La
> -Original Message-
> From: Jean-Michel POURE [mailto:[EMAIL PROTECTED]]
> Sent: 25 February 2002 11:25
> To: Dave Page
> Cc: [EMAIL PROTECTED]
> Subject: Re: [pgadmin-hackers] [ODBC] pgAdmin2 UTF-8 support
>
>
> Le Lundi 25 Février 2002 10:55, Dave Page a écrit :
> > Does it matter?
> I tried EUC_JP, it does work.
Sorry, I meant it does NOT work.
Le Lundi 25 Février 2002 10:55, Dave Page a écrit :
> Does it matter? I thought it was the client encoding that mattered: I would
> guess that it should be set to EUC_JP.
Yes, it matters. EUC_JP is a unix encoding. It will never display under
Windows.
Jean-Michel
Hmm - interesting idea. We werent able to display or enter hebrew chars in
Pgadmin2 because apparently the VB objects it uses dont support hebrew. Let
me try and I'll get back to you real soon
danny
Le Lundi 25 Février 2002 10:55, vous avez écrit :
> Does it matter? I thought it was the client encoding that mattered: I would
> guess that it should be set to EUC_JP.
I tried EUC_JP, it does work. This is a Japanese encoding for Unixes. We need
its Windows equivalent, if exists. It could be ad
> -Original Message-
> From: Jean-Michel POURE [mailto:[EMAIL PROTECTED]]
> Sent: 25 February 2002 09:42
> To: Dave Page
> Cc: [EMAIL PROTECTED]
> Subject: Re: [pgadmin-hackers] [ODBC] pgAdmin2 UTF-8 support
>
>
> Le Lundi 25 Février 2002 10:23, Dave Page a écrit :
> > Cool. Is it pos
Dear Danny,
Could you try pgAdmin2 and enter 'SET CLIENT_ENCODING = ISO-8859-8'. Then try
to display data in pgAdmin2. Does it work?
Information can be found at
http://developer.postgresql.org/docs/postgres/multibyte.html#AEN16680
Cheers,
Jean-Michel POURE
Le Lundi 25 Février 2002 10:23, Dave Page a écrit :
> Cool. Is it possible for you to try a simple test on one of your Japanese
> databases?
I don't knwo the Windows encodings names.
Le Lundi 25 Février 2002 10:02, Dave Page a écrit :
> So, to get this straight in my non multilingual brain, if you set client
> encoding to latin1 then european charsets (i.e. latin based) work perfectly
> in pgAdmin?
Have a look at :
http://www.postgresql.org/idocs/index.php?multibyte.html#AEN
> We have a Unicode hebrew db in PG7.2. Uou dont need to write the functions
> and views in UTF-8 unless you have some
> literals inside the code. We had this issue with Hebrew; so we store all
> the literals as tokens in another table which may have some overhead but
> makes for great flexibili
> -Original Message-
> From: Jean-Michel POURE [mailto:[EMAIL PROTECTED]]
> Sent: 25 February 2002 09:15
> To: Dave Page
> Cc: [EMAIL PROTECTED]
> Subject: Re: [pgadmin-hackers] [ODBC] pgAdmin2 UTF-8 support
>
>
> Le Lundi 25 Février 2002 10:02, Dave Page a écrit :
> > So, to get this
Le Lundi 25 Février 2002 10:02, Dave Page a écrit :
> So, to get this straight in my non multilingual brain, if you set client
> encoding to latin1 then european charsets (i.e. latin based) work perfectly
> in pgAdmin?
Yes.
> So probably we need to _at least_ do something similar for Japanese/Heb
> -Original Message-
> From: Jean-Michel POURE [mailto:[EMAIL PROTECTED]]
> Sent: 25 February 2002 08:51
> To: Dave Page
> Cc: [EMAIL PROTECTED]
> Subject: Re: [pgadmin-hackers] [ODBC] pgAdmin2 UTF-8 support
>
>
> > OK, what about if you select the data back in pgAdmin -
> does it th
> OK, what about if you select the data back in pgAdmin - does it then
> display it?
Sure, it does. This is a new feature of PostgreSQL 7.2.
> Also, does SET CLIENT_ENCODING SQL_ASCII; work?
No it does not. "é" is stored as 'i'.
> -Original Message-
> From: Jean-Michel POURE [mailto:[EMAIL PROTECTED]]
> Sent: 25 February 2002 08:39
> To: Dave Page
> Cc: [EMAIL PROTECTED]
> Subject: Re: [pgadmin-hackers] [ODBC] pgAdmin2 UTF-8 support
>
>
> Le Lundi 25 Février 2002 09:29, Dave Page a écrit :
> > SET CLIENT_ENCO
Le Lundi 25 Février 2002 09:29, Dave Page a écrit :
> SET CLIENT_ENCODING Latin1;
> INSERT INTO table_foo (field_bar) VALUES ('é'); SELECT field_bar FROM
> table_foo WHERE field_bar='é';
In case of an UTF-8 database,
- schema queries should always be sent in Latin1.
- SQL highlightbox should allo
> -Original Message-
> From: Jean-Michel POURE [mailto:[EMAIL PROTECTED]]
> Sent: 25 February 2002 08:30
> To: Dave Page
> Cc: [EMAIL PROTECTED]
> Subject: Re: [pgadmin-hackers] [ODBC] pgAdmin2 UTF-8 support
>
>
> Le Lundi 25 Février 2002 09:29, Dave Page a écrit :
> > Presumably we s
Le Lundi 25 Février 2002 09:29, Dave Page a écrit :
> Presumably we should do this in SQL (I don't think you can do it in the
> ODBC connect string can you?). Have you tried in pgAdmin:
>
> SET CLIENT_ENCODING Latin1;
> INSERT INTO table_foo (field_bar) VALUES ('é'); SELECT field_bar FROM
> table_
> -Original Message-
> From: Jean-Michel POURE [mailto:[EMAIL PROTECTED]]
> Sent: 25 February 2002 08:18
> To: Dave Page
> Cc: [EMAIL PROTECTED]
> Subject: Re: [pgadmin-hackers] [ODBC] pgAdmin2 UTF-8 support
>
>
> Dear Dave,
>
> I used pgsql with PostgreSQL 7.2 and noticed there was
Jean Michel
We have a Unicode hebrew db in PG7.2. Uou dont need to write the functions
and views in UTF-8 unless you have some
literals inside the code. We had this issue with Hebrew; so we store all
the literals as tokens in another table which may have some overhead but
makes for great flexibi
Dear Dave,
I used pgsql with PostgreSQL 7.2 and noticed there was an automatic
translation between UTF-8 <-> Latin characters. This is a new feature of
PostgreSQL 7.2.
So fine :
Suppose we have a Unicode database :
\Encoding Latin1 (\same with \Encoding SQL_ASCII does not work)
INSERT INTO ta
> -Original Message-
> From: Jean-Michel POURE [mailto:[EMAIL PROTECTED]]
> Sent: 24 February 2002 23:07
> To: Dave Page
> Cc: [EMAIL PROTECTED]
> Subject: Re: Working oin pgAdmin2
>
>
> > I think the most effective way to go would be to write new classes
> > pgSchema.ODBCServer, pgS
31 matches
Mail list logo