Re: [JDBC] DatabaseMetadata problems
[JDBC driver ignores catalog and schema] On Fri, 07 Sep 2001 09:58:36 -0400, Tom Lane wrote: I think it'd be a mistake to expend much effort on this issue in JDBC right now. We will eventually implement SQL92-compliant schemas in the backend, and once that happens it'll be possible to do something reasonable with the catalog metadata routines in JDBC. If you try to make a half-usable implementation now, you'll just create backwards- compatibility issues for the real implementation later. So my counsel is: acknowledge that it's broken, but ignore it for now. I agree. I've added this to http://lab.applinet.nl/postgresql-jdbc/: PostgreSQL currently does not support SQL92 compliant catalogs and schemas. With a number of methods (getColumns, getTables, getProcedures and such) the JDBC driver ignores the catalog and schema or schemaPattern parameters. getColumns() returns an empty string (should be null) in the fields TABLE_CAT and TABLE_SCHEM. getTables() returns null in TABLE_CAT and TABLE_SCHEM. getProcedures() returns null in PROCEDURE_CAT and PROCEDURE_SCHEM. Regards, René Pijlman [EMAIL PROTECTED] ---(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] Need help with JDBC driver. Problem, - getExportedKeys=
On Sat, 01 Sep 2001 17:43:39 +0200, you wrote: I've tried the jxdbcon driver now and it gives another view of the actual database... I am not a PostgreSQL guy so I am quite confused here. Anyway, this one seems to give the most appropriate view of the database since the system tables are listed which the pgsql drivers did not list. Yes, I noticed that DatabaseMetaData.getColumns() in the standard PostgreSQL driver returns the columns of the system tables, whereas getTables() does not return those tables. I guess that should be fixed. So documented on http://lab.applinet.nl/postgresql-jdbc/ Could anyone point me to a place where I can download/get some simple SQL statements to create at least relationsships between two tables? See the section Reference constraint on http://www.postgresql.org/users-lounge/docs/7.1/reference/sql-createtable.html Regards, René Pijlman [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [JDBC] Regarding Error installing jdbc7.0-1.2.jar
On Sun, 09 Sep 2001 14:25:38 +0530, you wrote: Then, I tried to install the jar file for jdbc 'jdbc7.0-1.2. jar' and extracted it to the directory /usr/lib/pgsql. Never extract the contents of these jar files! http://jdbc.postgresql.org/docs/#install Put it in your CLASSPATH instead. 7.0 is pretty old by the way. You may want to get the latest release of the driver from http://jdbc.fastcrypt.com/. But then again, expect some problems when you use the latest release of the driver against a 7.0 backend (7.1 is OK). Regards, René Pijlman [EMAIL PROTECTED] ---(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] Regarding Error installing jdbc7.0-1.2.jar
I'm not sure if you get this message via the list, but if you post an a mailing list it would be nice if your address worked. - Transcript of session follows - ... while talking to mail.ceedees.com.: RCPT To:[EMAIL PROTECTED] 550 [EMAIL PROTECTED]... Relaying denied 550 [EMAIL PROTECTED]... User unknown Regards, René Pijlman [EMAIL PROTECTED] ---(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
Re: [JDBC] [HACKERS] JDBC pg_description update needed for CVS tip
On Sun, 09 Sep 2001 14:48:41 +0200, you wrote: It is of course a performance improvement if it uses only 1 SQL statement rather than N+1 with N being the number of columns reported. E.g. if you list all columns of all tables in a big database, this would be a huge win. I think that can only be decided by measurement. What you're saying is: 1 * c1 (N + 1) * c2 but that can only be decided if we know c1 and c2 (meaning: the execution times of two different queries, including round trip overhead). That doesn't mean I'm opposed to the change, on the contrary. As a rule, I find a complex SQL statement more elegant than the same 'algorithm' in procedural code. But in this case I wasn't sure how to construct it. Regards, René Pijlman [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[JDBC] Fix DatabaseMetaDataTest in JDBC test suite
Attached is a patch that fixes DatabaseMetaDataTest in the JDBC
driver's test suite. With previous patches applied, this reduces
the number of failures of the test suite from 6 to 4. The patch
fixes the test case itself, rather than the driver.
Details:
1) The driver correctly provided DatabaseMetaData about the sort
order of NULLs. This was confirmed by Peter Eisentraut on
pgsql-hackers. I fixed the test to accept/require the current
behaviour, and made it dependent on the backend version. See
nullsAreSortedAtStart(), nullsAreSortedAtEnd(),
nullsAreSortedHigh() and nullsAreSortedLow().
2) DatabaseMetaData.supportsOrderByUnrelated() correctly
returned true (an ORDER BY clause can contain columns that are
not in the SELECT clause), but the test case required false.
Fixed that.
3) Replaced deprecated assert() of junit.framework.TestCase by
assertEquals(), assertTrue() and assertNotNull(). This is
because assert will be a new keyword in Java 1.4.
4) Replaced assert(message,false) by the more elegant
fail(message).
Regards,
René Pijlman [EMAIL PROTECTED]
Index: org/postgresql/test/jdbc2/DatabaseMetaDataTest.java
===
RCS file:
/home/projects/pgsql/cvsroot/pgsql/src/interfaces/jdbc/org/postgresql/test/jdbc2/DatabaseMetaDataTest.java,v
retrieving revision 1.1
diff -c -r1.1 DatabaseMetaDataTest.java
*** org/postgresql/test/jdbc2/DatabaseMetaDataTest.java 2001/02/13 16:39:05 1.1
--- org/postgresql/test/jdbc2/DatabaseMetaDataTest.java 2001/09/09 14:04:42
***
*** 29,39
Connection con = JDBC2Tests.openDB();
DatabaseMetaData dbmd = con.getMetaData();
! assert(dbmd!=null);
JDBC2Tests.closeDB(con);
} catch(SQLException ex) {
! assert(ex.getMessage(),false);
}
}
--- 29,39
Connection con = JDBC2Tests.openDB();
DatabaseMetaData dbmd = con.getMetaData();
! assertNotNull(dbmd);
JDBC2Tests.closeDB(con);
} catch(SQLException ex) {
! fail(ex.getMessage());
}
}
***
*** 45,76
Connection con = JDBC2Tests.openDB();
DatabaseMetaData dbmd = con.getMetaData();
! assert(dbmd!=null);
! assert(dbmd.allProceduresAreCallable()==true);
! assert(dbmd.allTablesAreSelectable()==true); // not true all the time
// This should always be false for postgresql (at least for 7.x)
! assert(!dbmd.isReadOnly());
// does the backend support this yet? The protocol does...
! assert(!dbmd.supportsMultipleResultSets());
// yes, as multiple backends can have transactions open
! assert(dbmd.supportsMultipleTransactions());
! assert(dbmd.supportsMinimumSQLGrammar());
! assert(!dbmd.supportsCoreSQLGrammar());
! assert(!dbmd.supportsExtendedSQLGrammar());
! assert(!dbmd.supportsANSI92EntryLevelSQL());
! assert(!dbmd.supportsANSI92IntermediateSQL());
! assert(!dbmd.supportsANSI92FullSQL());
! assert(!dbmd.supportsIntegrityEnhancementFacility());
JDBC2Tests.closeDB(con);
} catch(SQLException ex) {
! assert(ex.getMessage(),false);
}
}
--- 45,76
Connection con = JDBC2Tests.openDB();
DatabaseMetaData dbmd = con.getMetaData();
! assertNotNull(dbmd);
! assertTrue(dbmd.allProceduresAreCallable());
! assertTrue(dbmd.allTablesAreSelectable()); // not true all the time
// This should always be false for postgresql (at least for 7.x)
! assertTrue(!dbmd.isReadOnly());
// does the backend support this yet? The protocol does...
! assertTrue(!dbmd.supportsMultipleResultSets());
// yes, as multiple backends can have transactions open
! assertTrue(dbmd.supportsMultipleTransactions());
! assertTrue(dbmd.supportsMinimumSQLGrammar());
! assertTrue(!dbmd.supportsCoreSQLGrammar());
! assertTrue(!dbmd.supportsExtendedSQLGrammar());
! assertTrue(!dbmd.supportsANSI92EntryLevelSQL());
! assertTrue(!dbmd.supportsANSI92IntermediateSQL());
! assertTrue(!dbmd.supportsANSI92FullSQL());
! assertTrue(!dbmd.supportsIntegrityEnhancementFacility());
JDBC2Tests.closeDB(con);
} catch(SQLException ex) {
! fail(ex.getMessage());
}
}
***
*** 80,94
Connection con = JDBC2Tests.openDB();
DatabaseMetaData dbmd = con.getMetaData();
! assert(dbmd!=null);
! assert(dbmd.supportsOuterJoins());
! assert(dbmd.supportsFullOuterJoins());
! assert(dbmd.supportsLimitedOuterJoins());
JDBC2Tests.closeDB(con);
} catch(SQLException ex) {
! assert(ex.getMessage(),false);
}
}
--- 80,94
Connection con = JDBC2Tests.openDB();
DatabaseMetaData dbmd = con.getMetaData();
! assertNotNull(dbmd);
!
Re: [HACKERS] [JDBC] Troubles using German Umlauts with JDBC
I can add something if people agree there is an issue here. I've added a new section Character encoding to http://lab.applinet.nl/postgresql-jdbc/, based on the information from Dave and Barry. I haven't seen a confirmation from pgsql-hackers or Bruce yet that this issue will be added to the Todo list. I'm under the impression that the backend developers don't see this as a problem. Regards, Ren? Pijlman On Tue, 04 Sep 2001 10:40:36 -0700, Barry Lind wrote: I would like to add one additional comment. In current sources the jdbc driver detects (through a hack) that the server doesn't have multibyte enabled and then ignores the SQL_ASCII return value and defaults to the JVM's character set instead of using SQL_ASCII. The problem boils down to the fact that without multibyte enabled, the server has know way of specifiying which 8bit character set is being used for a particular database. Thus a client like JDBC doesn't know what character set to use when converting to UNICODE. Thus the best we can do in JDBC is use our best guess (JVM character set is probably the best default), and allow the user to explicitly specify something else if necessary. thanks, --Barry Rene Pijlman wrote: [forwarding to pgsql-hackers and Bruce as Todo list maintainer, see comment below] [insert with JDBC converts Latin-1 umlaut to ?] On 04 Sep 2001 09:54:27 -0400, Dave Cramer wrote: You have to set the encoding when you make the connection. Properties props = new Properties(); props.put(user,user); props.put(password,password); props.put(charSet,encoding); Connection con = DriverManager.getConnection(url,props); where encoding is the proper encoding for your database For completeness, I quote the answer Barry Lind gave yesterday. [the driver] asks the server what character set is being used for the database. Unfortunatly the server only knows about character sets if multibyte support is compiled in. If the server is compiled without multibyte, then it always reports to the client that the character set is SQL_ASCII (where SQL_ASCII is 7bit ascii). Thus if you don't have multibyte enabled on the server you can't support 8bit characters through the jdbc driver, unless you specifically tell the connection what character set to use (i.e. override the default obtained from the server). This really is confusing and I think PostgreSQL should be able to support single byte encoding conversions without enabling multi-byte. To the very least there should be a --enable-encoding-conversion or something similar, even if it just enables the current multibyte support. Bruce, can this be put on the TODO list one way or the other? This problem has appeared 4 times in two months or so on the JDBC list. Regards, Ren? Pijlman [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] [JDBC] Troubles using German Umlauts with JDBC
On Sun, 9 Sep 2001 10:24:32 -0400 (EDT), Bruce Momjian wrote: I can add something if people agree there is an issue here. IMO the issue is twofold. Without multibyte compiled in: 1) the server cannot tell the client which single byte character encoding is being used, so a client like JDBC cannot properly convert to its native encoding 2) its not possible to create a database with a single byte encoding other than ASCII (see my posting http://fts.postgresql.org/db/mw/msg.html?mid=1029462) I'm not sure to what extent these issues are related. Also, client/server character conversion is coupled to multibyte support (see Peter's reply to my posting). This may be a limitation for other clients, but I'm not sure about that. Basically, it seems that multibyte support is adding features that are needed in single byte environents as well. Perhaps the problem can be solved by documentation (recommending to enable multibyte support in non-ASCII singlebyte environments), perhaps by an alias (--enable-character-encoding), perhaps the functionality needs to be split into a true multibyte part and a generic part. I don't know what's best, this probably depends on the price of compiling in multibyte support. Regards, René Pijlman I've added a new section Character encoding to http://lab.applinet.nl/postgresql-jdbc/, based on the information from Dave and Barry. I haven't seen a confirmation from pgsql-hackers or Bruce yet that this issue will be added to the Todo list. I'm under the impression that the backend developers don't see this as a problem. Regards, Ren? Pijlman On Tue, 04 Sep 2001 10:40:36 -0700, Barry Lind wrote: I would like to add one additional comment. In current sources the jdbc driver detects (through a hack) that the server doesn't have multibyte enabled and then ignores the SQL_ASCII return value and defaults to the JVM's character set instead of using SQL_ASCII. The problem boils down to the fact that without multibyte enabled, the server has know way of specifiying which 8bit character set is being used for a particular database. Thus a client like JDBC doesn't know what character set to use when converting to UNICODE. Thus the best we can do in JDBC is use our best guess (JVM character set is probably the best default), and allow the user to explicitly specify something else if necessary. thanks, --Barry Rene Pijlman wrote: [forwarding to pgsql-hackers and Bruce as Todo list maintainer, see comment below] [insert with JDBC converts Latin-1 umlaut to ?] On 04 Sep 2001 09:54:27 -0400, Dave Cramer wrote: You have to set the encoding when you make the connection. Properties props = new Properties(); props.put(user,user); props.put(password,password); props.put(charSet,encoding); Connection con = DriverManager.getConnection(url,props); where encoding is the proper encoding for your database For completeness, I quote the answer Barry Lind gave yesterday. [the driver] asks the server what character set is being used for the database. Unfortunatly the server only knows about character sets if multibyte support is compiled in. If the server is compiled without multibyte, then it always reports to the client that the character set is SQL_ASCII (where SQL_ASCII is 7bit ascii). Thus if you don't have multibyte enabled on the server you can't support 8bit characters through the jdbc driver, unless you specifically tell the connection what character set to use (i.e. override the default obtained from the server). This really is confusing and I think PostgreSQL should be able to support single byte encoding conversions without enabling multi-byte. To the very least there should be a --enable-encoding-conversion or something similar, even if it just enables the current multibyte support. Bruce, can this be put on the TODO list one way or the other? This problem has appeared 4 times in two months or so on the JDBC list. Regards, Ren? Pijlman [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl ---(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
Re: [HACKERS] [JDBC] Troubles using German Umlauts with JDBC
I've added a new section Character encoding to http://lab.applinet.nl/postgresql-jdbc/, based on the information from Dave and Barry. I haven't seen a confirmation from pgsql-hackers or Bruce yet that this issue will be added to the Todo list. I'm under the impression that the backend developers don't see this as a problem. Regards, René Pijlman On Tue, 04 Sep 2001 10:40:36 -0700, Barry Lind wrote: I would like to add one additional comment. In current sources the jdbc driver detects (through a hack) that the server doesn't have multibyte enabled and then ignores the SQL_ASCII return value and defaults to the JVM's character set instead of using SQL_ASCII. The problem boils down to the fact that without multibyte enabled, the server has know way of specifiying which 8bit character set is being used for a particular database. Thus a client like JDBC doesn't know what character set to use when converting to UNICODE. Thus the best we can do in JDBC is use our best guess (JVM character set is probably the best default), and allow the user to explicitly specify something else if necessary. thanks, --Barry Rene Pijlman wrote: [forwarding to pgsql-hackers and Bruce as Todo list maintainer, see comment below] [insert with JDBC converts Latin-1 umlaut to ?] On 04 Sep 2001 09:54:27 -0400, Dave Cramer wrote: You have to set the encoding when you make the connection. Properties props = new Properties(); props.put(user,user); props.put(password,password); props.put(charSet,encoding); Connection con = DriverManager.getConnection(url,props); where encoding is the proper encoding for your database For completeness, I quote the answer Barry Lind gave yesterday. [the driver] asks the server what character set is being used for the database. Unfortunatly the server only knows about character sets if multibyte support is compiled in. If the server is compiled without multibyte, then it always reports to the client that the character set is SQL_ASCII (where SQL_ASCII is 7bit ascii). Thus if you don't have multibyte enabled on the server you can't support 8bit characters through the jdbc driver, unless you specifically tell the connection what character set to use (i.e. override the default obtained from the server). This really is confusing and I think PostgreSQL should be able to support single byte encoding conversions without enabling multi-byte. To the very least there should be a --enable-encoding-conversion or something similar, even if it just enables the current multibyte support. Bruce, can this be put on the TODO list one way or the other? This problem has appeared 4 times in two months or so on the JDBC list. Regards, René Pijlman [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [JDBC] NULLs and sort order
Rene Pijlman writes: Currently the JDBC driver says: - Backend = 7.2 sorts nulls higher than any other value in a domain. In other words: ascending means nulls at the end, descending means nulls at the start. - Backend 7.2 puts nulls at the end regardless of sort order. That is correct. Would it be useful to add this information to the documentation, e.g. the documentation of ORDER BY in SELECT? Most likely. -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [JDBC] NULLs and sort order
On Sun, 9 Sep 2001 15:25:17 +0200 (CEST), you wrote: That is correct. Thanks. Would it be useful to add this information to the documentation, e.g. the documentation of ORDER BY in SELECT? Most likely. I'll post it on the docs list. Regards, René Pijlman [EMAIL PROTECTED] ---(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] Timezones and time/timestamp values in FE/BE protocol
I'm working on a problem in the JDBC driver that's related to timezones. How does PostgreSQL handle timezones in the FE/BE protocol exactly? When a client sends a time or timestamp value to the server via the FE/BE protocol, should that be: 1) a value in the client's timezone? 2) a value in the server's timezone? 3) a value in a common frame of reference (GMT/UTC)? 4) any value with an explicit timezone? And how should a time or timestamp value returned by the server be interpreted in the client interface? And how does this all depend on the timezone setting of the server? Regards, René Pijlman [EMAIL PROTECTED] ---(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
Re: [JDBC] Timezones and time/timestamp values in FE/BE protocol
On Sun, 09 Sep 2001 13:38:52 -0700, you wrote: [...] Thanks for your explanation. This helps a lot. If you could post a bit more about the issue you are having I might be able to be more specific. I'm looking at the 4 remaining failures of our own JDBC test suite. They all have to do with timestamps and times, and they are all caused by a 1 hour shift between the expected value and the actual value. I run both the backend and the JVM on the same Linux test server. Its located in Amsterdam, The Netherlands, Central European Daylight Savings Time (CETDST, UTC+2, GMT+2). I always thought I was in CET=GMT+1, but now the offset is 2, because of daylight saving time (whoever invented that should be #!$^). Perhaps I should go live in Greenwich, they don't seem to have daylight saving time overthere. In psql I see: show timezone; NOTICE: Time zone is unset Here is some detailed information about the failures. I'm refering to line numbers in 7.2 current CVS: TimeTest.java revision 1.1 TimestampTest.java revision 1.2 1) TimeTest.java:89 getHours(t) expected 1, actual 0 t.toString() returns the expected 01:02:03, but this is because java.sql.Time.toString() converts to the JVM's timezone. 2) TimeTest.java:96 getHours(t) expected 23, actual 0 t.toString returns 00:59:59 3) TimestampTest.java:115 Expected: getTimestamp(1970,6,2,8,13,0) returns 1970-06-02 08:13:00.0 Actual: t.toString() returns 1970-06-02 09:13:00.0 4) TimestampTest.java:115 (second time around) Expected: getTimestamp(1970,6,2,8,13,0) returns 1970-06-02 08:13:00.0 Actual: t.toString() returns 1970-06-02 07:13:00.0 My first impression is that in all cases a timezone shift is applied in only one direction (store vs. retrieve). The cause might also be a problem with daylight saving time, there are some comments about that in TimestampTest.java. Up till now I've managed without a graphical debugger, but to get a good feel for what's happening between the test code and the wire I think it'll be easier to setup JBuilder with the driver and step through the code. But now its almost bedtime in my timezone, and you never know with these mailing lists. Sometimes the solution is in your inbox when you wake up :-) Regards, René Pijlman [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [JDBC] Something unusual has occured to cause the driver to
Your connection url looks funny, it should probably be more like jdbc:postgresql://localhost/testdb dave On Sun, 9 Sep 2001, Larry Rogers wrote: exception: Exception: java.lang.NullPointerException Stack Trace: java.lang.NullPointerException at org.postgresql.Connection.openConnection(Connection.java:148) at org.postgresql.Driver.connect(Driver.java:122) at java.sql.DriverManager.getConnection(DriverManager.java:517) at java.sql.DriverManager.getConnection(DriverManager.java:177) at TestPostGreSQL.main(TestPostGreSQL.java:17) End of Stack Trace final String url = jdbc:postgresql://localhost:5432?database=testdb; -- Dave Weis I believe there are more instances of the abridgement [EMAIL PROTECTED] of the freedom of the people by gradual and silent encroachments of those in power than by violent and sudden usurpations.- James Madison ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [JDBC] Something unusual has occured to cause the driver to fail. NullPointerException
I tried your URL format with the same results. Thanks anyway! Larry Rogers On Sunday 09 September 2001 20:15, Dave Weis wrote: Your connection url looks funny, it should probably be more like jdbc:postgresql://localhost/testdb dave ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [JDBC] Troubles using German Umlauts with JDBC
Added to TODO. Bruce, I think the TODO item should be: Ability to set character set for a database without multibyte enabled Currently createdb -E (and the corresponding create database sql command) only works if multibyte is enabled. However it is useful to know which single byte character set is being used even when multibyte isn't enabled. Currently there is no way to specify which single byte character set a database is using (unless you compile with multibyte). thanks, --Barry Bruce Momjian wrote: I can add something if people agree there is an issue here. I've added a new section Character encoding to http://lab.applinet.nl/postgresql-jdbc/, based on the information from Dave and Barry. I haven't seen a confirmation from pgsql-hackers or Bruce yet that this issue will be added to the Todo list. I'm under the impression that the backend developers don't see this as a problem. Regards, Ren? Pijlman On Tue, 04 Sep 2001 10:40:36 -0700, Barry Lind wrote: I would like to add one additional comment. In current sources the jdbc driver detects (through a hack) that the server doesn't have multibyte enabled and then ignores the SQL_ASCII return value and defaults to the JVM's character set instead of using SQL_ASCII. The problem boils down to the fact that without multibyte enabled, the server has know way of specifiying which 8bit character set is being used for a particular database. Thus a client like JDBC doesn't know what character set to use when converting to UNICODE. Thus the best we can do in JDBC is use our best guess (JVM character set is probably the best default), and allow the user to explicitly specify something else if necessary. thanks, --Barry Rene Pijlman wrote: [forwarding to pgsql-hackers and Bruce as Todo list maintainer, see comment below] [insert with JDBC converts Latin-1 umlaut to ?] On 04 Sep 2001 09:54:27 -0400, Dave Cramer wrote: You have to set the encoding when you make the connection. Properties props = new Properties(); props.put(user,user); props.put(password,password); props.put(charSet,encoding); Connection con = DriverManager.getConnection(url,props); where encoding is the proper encoding for your database For completeness, I quote the answer Barry Lind gave yesterday. [the driver] asks the server what character set is being used for the database. Unfortunatly the server only knows about character sets if multibyte support is compiled in. If the server is compiled without multibyte, then it always reports to the client that the character set is SQL_ASCII (where SQL_ASCII is 7bit ascii). Thus if you don't have multibyte enabled on the server you can't support 8bit characters through the jdbc driver, unless you specifically tell the connection what character set to use (i.e. override the default obtained from the server). This really is confusing and I think PostgreSQL should be able to support single byte encoding conversions without enabling multi-byte. To the very least there should be a --enable-encoding-conversion or something similar, even if it just enables the current multibyte support. Bruce, can this be put on the TODO list one way or the other? This problem has appeared 4 times in two months or so on the JDBC list. Regards, Ren? Pijlman [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(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] Something unusual has occured to cause the driver to fail. NullPointerException
Larry,
Shouldn't your connection URL be:
jdbc:postgresql://localhost:5432/testdb
instead of
jdbc:postgresql://localhost:5432?database=testdb
thanks,
--Barry
Larry Rogers wrote:
Hi all,
I'm having trouble opening a database connection to a test database on a
fresh PostGreSQL 7.1.3 installation on RedHat 7.1 from the RPMs. I have a
simple test class TestPostGreSQL that opens a connection, queries for all the
rows in a table and prints the results to standard output. The driver file
is in the same directory as the java class, which I execute using
java -classpath .:jdbc7.1-1.2.jar TestPostGreSQL
I get the following error message:
Something unusual has occured to cause the driver to fail. Please report this
exception: Exception: java.lang.NullPointerException
Stack Trace:
java.lang.NullPointerException
at org.postgresql.Connection.openConnection(Connection.java:148)
at org.postgresql.Driver.connect(Driver.java:122)
at java.sql.DriverManager.getConnection(DriverManager.java:517)
at java.sql.DriverManager.getConnection(DriverManager.java:177)
at TestPostGreSQL.main(TestPostGreSQL.java:17)
End of Stack Trace
I created the database using
createdb testdb
and from psql created the table as
create table Person (
FirstName char(30) not null,
LastName char(30) not null);
then created the user and password and granted all permissions on the Person
table.
I start the server with
postmaster -i
to get TCP/IP support. The code for the test class is at the end of this
message. Note that everything is commented out except for loading the driver
and opening a connection. I have used JDBC successfully for months with
Microsoft SQL Server, but I'm anxious to switch over to PostGreSQL!
Thanks in advance for any help!
Larry Rogers
*
import java.sql.*;
import java.util.Date;
public class TestPostGreSQL {
public static void main(String[] args) {
final String driver = org.postgresql.Driver;
final String url = jdbc:postgresql://localhost:5432?database=testdb;
final String login = TestUser;
final String password = TestPass;
String sql = SELECT * FROM Person;
try {
Class.forName(driver);
Connection connection
= DriverManager.getConnection(url, login, password);
/*
Statement statement = connection.createStatement();
ResultSet result = statement.executeQuery(sql);
while (result.next()) {
System.out.println(result.getString(FirstName) + +
result.getString(LastName));
}
result.close();
statement.close();
*/
connection.close();
} catch(SQLException e) {
System.out.println(e);
} catch(ClassNotFoundException e) {
System.out.println(e);
}
}
}
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [JDBC] Troubles using German Umlauts with JDBC
General backend issue. --Barry Bruce Momjian wrote: Is this a jdbc issue or a general backend issue? Bruce, I think the TODO item should be: Ability to set character set for a database without multibyte enabled Currently createdb -E (and the corresponding create database sql command) only works if multibyte is enabled. However it is useful to know which single byte character set is being used even when multibyte isn't enabled. Currently there is no way to specify which single byte character set a database is using (unless you compile with multibyte). thanks, --Barry Bruce Momjian wrote: I can add something if people agree there is an issue here. I've added a new section Character encoding to http://lab.applinet.nl/postgresql-jdbc/, based on the information from Dave and Barry. I haven't seen a confirmation from pgsql-hackers or Bruce yet that this issue will be added to the Todo list. I'm under the impression that the backend developers don't see this as a problem. Regards, Ren? Pijlman On Tue, 04 Sep 2001 10:40:36 -0700, Barry Lind wrote: I would like to add one additional comment. In current sources the jdbc driver detects (through a hack) that the server doesn't have multibyte enabled and then ignores the SQL_ASCII return value and defaults to the JVM's character set instead of using SQL_ASCII. The problem boils down to the fact that without multibyte enabled, the server has know way of specifiying which 8bit character set is being used for a particular database. Thus a client like JDBC doesn't know what character set to use when converting to UNICODE. Thus the best we can do in JDBC is use our best guess (JVM character set is probably the best default), and allow the user to explicitly specify something else if necessary. thanks, --Barry Rene Pijlman wrote: [forwarding to pgsql-hackers and Bruce as Todo list maintainer, see comment below] [insert with JDBC converts Latin-1 umlaut to ?] On 04 Sep 2001 09:54:27 -0400, Dave Cramer wrote: You have to set the encoding when you make the connection. Properties props = new Properties(); props.put(user,user); props.put(password,password); props.put(charSet,encoding); Connection con = DriverManager.getConnection(url,props); where encoding is the proper encoding for your database For completeness, I quote the answer Barry Lind gave yesterday. [the driver] asks the server what character set is being used for the database. Unfortunatly the server only knows about character sets if multibyte support is compiled in. If the server is compiled without multibyte, then it always reports to the client that the character set is SQL_ASCII (where SQL_ASCII is 7bit ascii). Thus if you don't have multibyte enabled on the server you can't support 8bit characters through the jdbc driver, unless you specifically tell the connection what character set to use (i.e. override the default obtained from the server). This really is confusing and I think PostgreSQL should be able to support single byte encoding conversions without enabling multi-byte. To the very least there should be a --enable-encoding-conversion or something similar, even if it just enables the current multibyte support. Bruce, can this be put on the TODO list one way or the other? This problem has appeared 4 times in two months or so on the JDBC list. Regards, Ren? Pijlman [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
