Fwd: Re: Conversion between UNICODE and LATIN1 is not supported
От | Andreas Joseph Krogh |
---|---|
Тема | Fwd: Re: Conversion between UNICODE and LATIN1 is not supported |
Дата | |
Msg-id | 200304281301.29536.andreak@officenet.no обсуждение исходный текст |
Список | pgsql-jdbc |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - ---------- Forwarded Message ---------- Subject: Re: [JDBC] Conversion between UNICODE and LATIN1 is not supported Date: Monday 28 April 2003 12:54 From: Patrick Samson <p_samson@yahoo.com> To: andreak@officenet.no About your posting at pgsql-hackers in Dec last year. I know it's a long time ago, and you probably solved your problem now, but I experienced the same trouble. I found the solution by myself, but would have appreciate some clues in a response to your post. So I would like to share my solution, for the benefit of everyone. As I don't know how to publish a post without being a subscriber, I send you my message. May be you can manage to make it available in the archives. That would be nice for the community. - ---------------------------------- My environment is : pg 7.3.2 on Cygwin Everything was fine with pg 7.2. Then I transfered my DB to a new box freshly installed with pg7.3, and I had the conversion error between UNICODE and LATIN1 (or LATIN9). This is because the conversion management has changed: The conversions are implemented as Functions in the DB. Implementation is done by: /usr/local/pgsql/share/conversion_create.sql which is used in initdb. If you look in it, you will see references like: $libdir/<charSet1>_and_<charSet2> These are the names of DLLs. Unfortunatelly I followed the instructions in INSTALL / Post-Installation Setup: On Cygwin, ... move the ".dll" files into the "bin/" directory. This was OK for 7.2 (only 4 files), but for 7.3 the 26 additional conversion files are no more found in $libdir as expected, unless you try to alter this variable. I moved back the dlls in lib/ and added the directory to the PATH. Then I executed the conversion_create as mentioned in http://archives.postgresql.org/pgsql-hackers/2002-07/msg00747.php and saw that conversions were well performed. As this manual command put the functions in a specified DB (DB/Schemas/public/Functions with pgAdmin), I prefered to do an initdb again, so it appeas as a default (template1/Schemas/pg-catalog/Functions). Additional comment: With the problem, I was not able to use pg73jdbc2 or pg73jdbc3, but pg72jdbc2 was working. After the correction, pg73jdbc2|3 were OK. __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com - ------------------------------------------------------- - -- Andreas Joseph Krogh <andreak@officenet.no> We are programmers, not mind-readers. tom lane gpg public_key: http://dev.officenet.no/~andreak/public_key.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE+rQoJUopImDh2gfQRAkJUAJsEQVneYWMDn7fHzC3eLj3bo6dKXwCdFQd6 uhMxGzijRTNIPuQzbXHfVfo= =hLRL -----END PGP SIGNATURE-----
В списке pgsql-jdbc по дате отправления: