[JDBC] rpm jdbc installation
Hello! Assuming I have postgresql-jdbc-7.0.3-2 installed from an RPM on Red Hat 6.2 Do I have to follow the steps in http://jdbc.postgresql.org/docs/#install and start from sources ? Thanks in advance. -- Evelio MartÃnez ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[JDBC] Re: A bug with pgsql 7.1/jdbc and non-ascii (8-bit) chars?
On Thu, 3 May 2001, Barry Lind wrote: With regards to your specific problem, my guess is that you haven't created you database with the proper character set for the data you are storing in it. I am guessing you simply used the default SQL Acsii character set for your created database and therefore only the first 127 characters are defined. Any characters above 127 will be returned by java as ?'s. If this is the case you will need to recreate your database with the proper character set for the data you are storing in it and then everything should be fine. Thanks, you are right! The main problem was that I had not enabled the multibyte support for database. (I believe fairytale and supposed that correct locale setting will be enough.) So my humble wish is that the instructions in the INSTALL file should be corrected. Because: --enable-multibyte Allows the use of multibyte character encodings. This is primarily for languages like Japanese, Korean, and Chinese. Read the Administrator's Guide for details. I think that this is a little bit missleading. There is correct information in the Administrator's Guide, so I should have to read the Guide, but but... The world would be much better place, if there is little mention in the installation instruction that this concerns also 8-bit chars... But anyway, it works now very fine, thanks! BR, Jani --- Jani Averbach ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [JDBC] Re: A bug with pgsql 7.1/jdbc and non-ascii (8-bit) chars?
Barry Lind [EMAIL PROTECTED] writes: With regards to your specific problem, my guess is that you haven't created you database with the proper character set for the data you are storing in it. I am guessing you simply used the default SQL Acsii character set for your created database and therefore only the first 127 characters are defined. Any characters above 127 will be returned by java as ?'s. Does this happen with a non-multibyte-compiled database? If so, I'd argue that's a serious bug in the JDBC code: it makes JDBC unusable for non-ASCII 8-bit character sets, unless one puts up with the overhead of MULTIBYTE support. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [JDBC] Re: A bug with pgsql 7.1/jdbc and non-ascii (8-bit)chars?
On 04 May 2001 11:40:48 -0400, Tom Lane wrote: I fought with this for a few days. The solution is to dump the database and create a new database with the correct encoding. MULTIBYTE is not neccesary I just set the type to LATIN1 and it works fine. But a non-MULTIBYTE backend doesn't even have the concept of setting the encoding --- it will always just report SQL_ASCII. OK I just read the configure script for my backend - you guessed it multibyte support and locale support compiled in there... So createdb -E LATIN1 works just fine =:-b Perhaps what this really says is that it'd be better if the JDBC code assumed LATIN1 translations when the backend claims SQL_ASCII. Certainly, translating all high-bit-set characters to '?' is about as uselessly obstructionist a policy as I can think of... I will be adding this snippet to my doc on techdocs in the French version. It will save somebody a lot of head scratching. Cheers Tony Grant -- RedHat Linux on Sony Vaio C1XD/S http://www.animaproductions.com/linux2.html ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [JDBC] Re: A bug with pgsql 7.1/jdbc and non-ascii (8-bit)chars?
On 04 May 2001 10:29:50 -0400, Tom Lane wrote: With regards to your specific problem, my guess is that you haven't created you database with the proper character set for the data you are storing in it. I am guessing you simply used the default SQL Acsii character set for your created database and therefore only the first 127 characters are defined. Any characters above 127 will be returned by java as ?'s. Does this happen with a non-multibyte-compiled database? If so, I'd argue that's a serious bug in the JDBC code: it makes JDBC unusable for non-ASCII 8-bit character sets, unless one puts up with the overhead of MULTIBYTE support. I fought with this for a few days. The solution is to dump the database and create a new database with the correct encoding. MULTIBYTE is not neccesary I just set the type to LATIN1 and it works fine. Queries even work on accentuated caracters!!! I have a demo database for those interested Cheers Tony Grant -- RedHat Linux on Sony Vaio C1XD/S http://www.animaproductions.com/linux2.html Ultradev and PostgreSQL http://www.animaproductions.com/ultra.html ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [JDBC] Re: A bug with pgsql 7.1/jdbc and non-ascii (8-bit)chars?
On 04 May 2001 11:40:48 -0400, Tom Lane wrote: But a non-MULTIBYTE backend doesn't even have the concept of setting the encoding --- it will always just report SQL_ASCII. What kind of error message does createdb -E LATIN1 give on a non MULTIBYTE backend? Maybe there needs to be a note somewhere informing people from Europe that they too need MULTIBYTE as an option at compile time. i.e. In a bright yellow box in the HTML docs... And in the Reference manual and man pages the -E option for createdb needs a note to specify that it applies to MULTIBYTE backends only. Cheers Tony Grant -- RedHat Linux on Sony Vaio C1XD/S http://www.animaproductions.com/linux2.html ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [JDBC] Re: A bug with pgsql 7.1/jdbc and non-ascii (8-bit) chars?
Tony Grant [EMAIL PROTECTED] writes: What kind of error message does createdb -E LATIN1 give on a non MULTIBYTE backend? $ createdb -E LATIN1 foo /home/postgres/testversion/bin/createdb[143]: /home/postgres/testversion/bin/pg_encoding: not found. createdb: LATIN1 is not a valid encoding name $ Maybe there needs to be a note somewhere informing people from Europe that they too need MULTIBYTE as an option at compile time. i.e. In a bright yellow box in the HTML docs... But they *should not* need it, if they only want to use an 8-bit character set. Locale support should be enough. Or so I would think, anyway. I have to admit I have not looked very closely at the functionality that's enabled by MULTIBYTE; is any of it really needed to deal with LATINn character sets? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [JDBC] Bug-report (was: JDBC driver in pgsql 7.1 build problem)
On Thu, May 03, 2001 at 11:48:34PM +0200, Rolf Schillinger wrote:
Hi again,
it`s now offical, I found a bug in JDBC driver in pgsql 7.1 ;)
:)
I had the following problems:
/usr/local/jakarta-ant-1.3/bin//ant -buildfile ../../../build.xml
...
expected
[javac] return ${major};
...
when using
JDK:
java version 1.3.0
Java(TM) 2 Runtime Environment, Standard Edition (build
Blackdown-1.3.0-RC1)
Java HotSpot(TM) Client VM (build Blackdown-1.3.0-RC1, mixed mode)
Ant:
Ant version 1.3 compiled on March 2 2001
Postgresql:
As stated above: 7.1
To narrow the problem...
Has anybody had success compiling unpatched 7.1 JDBC driver
with JDK1.3 and Ant 1.2/1.3? If not, could this patch be
applied? Ant 1.4 betas seem to be ok.
--
marko
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
[JDBC] Re: A bug with pgsql 7.1/jdbc and non-ascii (8-bit) chars?
Tony Grant wrote: On 04 May 2001 11:40:48 -0400, Tom Lane wrote: But a non-MULTIBYTE backend doesn't even have the concept of setting the encoding --- it will always just report SQL_ASCII. What kind of error message does createdb -E LATIN1 give on a non MULTIBYTE backend? Maybe there needs to be a note somewhere informing people from Europe that they too need MULTIBYTE as an option at compile time. i.e. In a bright yellow box in the HTML docs... And in the Reference manual and man pages the -E option for createdb needs a note to specify that it applies to MULTIBYTE backends only. Cheers Tony Grant The errors you get are: from createdb- $ createdb -E LATIN1 testdb /usr/local/pgsql/bin/createdb: /usr/local/pgsql/bin/pg_encoding: No such file or directory createdb: LATIN1 is not a valid encoding name and from psql- template1=# create database testdb with encoding = 'LATIN1'; ERROR: Multi-byte support is not enabled thanks, --Barry ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [JDBC] Bug-report (was: JDBC driver in pgsql 7.1 build problem)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Date: Fri, 4 May 2001 19:26:48 +0200 From: Marko Kreen [EMAIL PROTECTED] Has anybody had success compiling unpatched 7.1 JDBC driver with JDK1.3 and Ant 1.2/1.3? If not, could this patch be applied? Ant 1.4 betas seem to be ok. Yes. I could compile 7.1 with ant 1.3 without a problem. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: Public key at http://www.keyserver.net iD8DBQE68vCUiysnOdCML0URAhaFAJwPk4muzSP6c5b+HCfZL/3N+KBv/ACdGke9 eFvhpOC1sWEeXmw9ozLfCR8= =rg36 -END PGP SIGNATURE- -- Virtually, Ned Wolpert [EMAIL PROTECTED] D08C2F45: 28E7 56CB 58AC C622 5A51 3C42 8B2B 2739 D08C 2F45 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [JDBC] Bug-report (was: JDBC driver in pgsql 7.1 build problem)
On Fri, May 04, 2001 at 09:16:38PM +0300, Ned Wolpert wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Date: Fri, 4 May 2001 19:26:48 +0200 From: Marko Kreen [EMAIL PROTECTED] Has anybody had success compiling unpatched 7.1 JDBC driver with JDK1.3 and Ant 1.2/1.3? If not, could this patch be applied? Ant 1.4 betas seem to be ok. Yes. I could compile 7.1 with ant 1.3 without a problem. And Sun's JDK 1.3? -- marko ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [JDBC] Re: A bug with pgsql 7.1/jdbc and non-ascii (8-bit) chars?
Barry Lind [EMAIL PROTECTED] writes: Now it is an easy change in the jdbc code to use LATIN1 when the server reports SQL_ASCII, but I really dislike hardcoding support that only works in english speaking countries and Western Europe. What's wrong with that? It won't be any more broken for people who are not really using LATIN1, and it will be considerably less broken for those who are. Seems like a net win to me, even without making the obvious point about where the majority of Postgres users are. It probably would be a good idea to allow the backend to store an indication of character set even when not compiled for MULTIBYTE, but that's not the issue here. To me, the issue is whether JDBC makes a reasonable effort not to munge data when presented with a backend that claims to be using SQL_ASCII (which, let me remind you, is the default setting). Converting high-bit-set characters to '?' is almost certainly NOT what the user wants you to do. Converting on the assumption of LATIN1 will make a lot of people happy, and the people who aren't happy with it will certainly not be happy with '?' conversion either. All this does is move the problem from being one that non-english countries have to being one where it is a non-english and non-western european problem (eg. Eastern Europe, Russia, etc.). Nonsense. The non-Western-European folks see broken behavior now anyway, unless they compile with MULTIBYTE and set an appropriate encoding. How would this make their lives worse, or even different? I'm merely suggesting that the default behavior could be made useful to a larger set of people than it now is, without making things any worse for those that it's not useful to. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [JDBC] rpm jdbc installation
no u don't need to follow those steps. but u still hav to set the classpath for the jdbc driver in this rpm. - Original Message - From: Evelio Martinez [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, May 04, 2001 1:13 PM Subject: [JDBC] rpm jdbc installation Hello! Assuming I have postgresql-jdbc-7.0.3-2 installed from an RPM on Red Hat 6.2 Do I have to follow the steps in http://jdbc.postgresql.org/docs/#install and start from sources ? Thanks in advance. -- Evelio MartÃnez ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
