[JDBC] Re: [PATCHES] DatabaseMetaData.getIndexInfo() added
Peter, can you comment on this patch?
Hi all!
Attached is a patch that implements DatabaseMetaData.getIndexInfo()
for the JDBC2 driver. It also fixes a compile error under jikes by
casting characters in case statements of a byte-compared switch to
bytes.
A few notes on getIndexInfo():
1.) getArray() is not implemented for the postgresql JDBC driver yet,
so getIndexInfo() parses the pg_index.indkey field into separate
integers by hand.
2.) I have guessed that if pg_index.indisclustered is "false", then
the index is "hashed"; if not, line 2561 of the resultant class
should have "tableIndexOther" rather than "tableIndexHashed".
3.) I didn't know what sort sequence (if any) was used in indexes, so
I have set it to "null" (unknown) on line 2566.
4.) For "CARDINALITY" (number of unique index items, the 11th field of
the ResultSet returned by getIndexInfo()) I have used
pg_classes.reltuples.
I have tested this method, but hardly extensively. Is there a proper
regression test suite for the JDBC driver that tests can be added to?
William
--
William Webber [EMAIL PROTECTED]
Senior Programmer
PeopleWeb Australia http://www.peopleweb.com
[ Attachment, skipping... ]
--
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
--- DatabaseMetaData.java.old Thu Feb 1 14:28:09 2001
+++ DatabaseMetaData.java Thu Feb 1 14:43:07 2001
@@ -1689,13 +1689,13 @@
String relKind;
switch (r.getBytes(3)[0]) {
- case 'r':
+ case (byte) 'r':
relKind = "TABLE";
break;
- case 'i':
+ case (byte) 'i':
relKind = "INDEX";
break;
- case 'S':
+ case (byte) 'S':
relKind = "SEQUENCE";
break;
default:
@@ -2515,11 +2515,10 @@
* @return ResultSet each row is an index column description
*/
// Implementation note: This is required for Borland's JBuilder to work
- public java.sql.ResultSet getIndexInfo(String catalog, String schema, String table,
boolean unique, boolean approximate) throws SQLException
+ public java.sql.ResultSet getIndexInfo(String catalog, String schema, String
+tableName, boolean unique, boolean approximate) throws SQLException
{
-// for now, this returns an empty result set.
Field f[] = new Field[13];
-ResultSet r; // ResultSet for the SQL query that we need to do
+java.sql.ResultSet r; // ResultSet for the SQL query that we need to do
Vector v = new Vector(); // The new ResultSet tuple stuff
f[0] = new Field(connection, "TABLE_CAT", iVarcharOid, 32);
@@ -2535,6 +2534,42 @@
f[10] = new Field(connection, "CARDINALITY", iInt4Oid, 4);
f[11] = new Field(connection, "PAGES", iInt4Oid, 4);
f[12] = new Field(connection, "FILTER_CONDITION", iVarcharOid, 32);
+
+r = connection.ExecSQL("select c.relname, x.indisunique, i.relname,
+x.indisclustered, x.indkey, c.reltuples, c.relpages, c.oid FROM pg_index x, pg_class
+c, pg_class i WHERE ((c.oid = x.indrelid) AND (i.oid = x.indexrelid) AND (c.relname =
+'" + tableName.toLowerCase() + "')) ORDER BY x.indisunique DESC, x.indisclustered,
+i.relname");
+while (r.next()) {
+// indkey is an array of column ordinals (integers). In the JDBC
+// interface, this has to be separated out into a separate
+// tuple for each indexed column. Also, getArray() is not yet
+// implemented for Postgres JDBC, so we parse by hand.
+String columnOrdinalString = r.getString(5);
+StringTokenizer stok = new StringTokenizer(columnOrdinalString);
+int [] columnOrdinals = new int[stok.countTokens()];
+int o = 0;
+while (stok.hasMoreTokens()) {
+columnOrdinals[o++] = Integer.parseInt(stok.nextToken());
+}
+for (int i = 0; i columnOrdinals.length; i++) {
+byte [] [] tuple = new byte [13] [];
+tuple[0] = "".getBytes();
+tuple[1] = "".getBytes();
+tuple[2] = r.getBytes(1);
+tuple[3] = r.getBoolean(2) ? "f".getBytes() : "t".getBytes();
+tuple[4] = null;
+tuple[5] = r.getBytes(3);
+tuple[6] = r.getBoolean(4)
+? Integer.toString(tableIndexClustered).getBytes()
+: Integer.toString(tableIndexHashed).getBytes(); // ??? I guess
+tuple[7] = Integer.toString(i + 1).getBytes();
+java.sql.ResultSet columnNameRS = connection.ExecSQL("
Re: [JDBC] Returning oid or primary key
However, _if_ RETURNING is going to be in the standard SQL for the next release, _and_ there are plans to update the jdbc driver to take advantage of that in the callable statement, as well, then it makes more sense _not_ to add my patch that implements the 'overloading' of the return value in the jdbc driver. I guess the issue is the ability to return the primary key from an inserted row, for cases that it's auto-generated, such as using the serial type. Certainly the portable solution is to get RETURNING into the backend so you can decide what you want to return. -- 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 4: Don't 'kill -9' the postmaster
Re: [JDBC] Re: Patch to remove connection hook and JDK 1.3 dependencies
The consensus was that the function didn't work or wasn't needed. We can always re-add it. I will wait for a discussion. If it doesn't work that's one thing but I think it is needed. Whenever I shut down my java programs I get 'pq_recvbuf: unexpected EOF on client connection ' in my postgres log. I was going to make my own shutdown hooks when I moved to java 1.3 but I noticed that there were ones in the jdbc driver so I thought I didn't have to. And when I kept getting those messages I just thought I built the driver wrong. Are you using the current CVS jdbc driver from: http://jdbc.fastcrypt.com or an older version? I hope it is at least 7.1.X. -- 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] DatabaseMetaData.getCatalogs()
I am Cc'ing the jdbc list. [[[ Original Message from Bruce Momjian [EMAIL PROTECTED] ]]] Just send over a context diff patch, either against 7.1.2 or CVS. Okay here's a context diff against CVS for getting table privileges. I may have more code to add (I noticed getColumnPrivileges() is not completed - could use my routine for parsing pg_class.relacl?). Jason Davies [EMAIL PROTECTED] [ Attachment, skipping... ] -- 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: [JDBC] Patch for handling long null terminated strings in JDBC driver
;
//--
*** ./interfaces/jdbc/org/postgresql/PG_Stream.java.orig Thu Jul 12 13:37:28
2001
--- ./interfaces/jdbc/org/postgresql/PG_Stream.java Thu Jul 12 13:54:03 2001
***
*** 23,28
--- 23,29
private Socket connection;
private InputStream pg_input;
private BufferedOutputStream pg_output;
+ private byte[] byte_buf = new byte[8*1024];
BytePoolDim1 bytePoolDim1 = new BytePoolDim1();
BytePoolDim2 bytePoolDim2 = new BytePoolDim2();
***
*** 200,271
}
/**
!* Receives a null-terminated string from the backend. Maximum of
!* maxsiz bytes - if we don't see a null, then we assume something
!* has gone wrong.
*
-* @param maxsiz maximum length of string
-* @return string from back end
-* @exception SQLException if an I/O error occurs
-*/
- public String ReceiveString(int maxsiz) throws SQLException
- {
- byte[] rst = bytePoolDim1.allocByte(maxsiz);
- return ReceiveString(rst, maxsiz, null);
- }
-
- /**
-* Receives a null-terminated string from the backend. Maximum of
-* maxsiz bytes - if we don't see a null, then we assume something
-* has gone wrong.
-*
-* @param maxsiz maximum length of string
* @param encoding the charset encoding to use.
-* @param maxsiz maximum length of string in bytes
* @return string from back end
!* @exception SQLException if an I/O error occurs
*/
! public String ReceiveString(int maxsiz, String encoding) throws SQLException
! {
! byte[] rst = bytePoolDim1.allocByte(maxsiz);
! return ReceiveString(rst, maxsiz, encoding);
! }
!
! /**
!* Receives a null-terminated string from the backend. Maximum of
!* maxsiz bytes - if we don't see a null, then we assume something
!* has gone wrong.
!*
!* @param rst byte array to read the String into. rst.length must
!*equal to or greater than maxsize.
!* @param maxsiz maximum length of string in bytes
!* @param encoding the charset encoding to use.
!* @return string from back end
!* @exception SQLException if an I/O error occurs
!*/
! public String ReceiveString(byte rst[], int maxsiz, String encoding)
throws SQLException
{
int s = 0;
!
! try
! {
! while (s maxsiz)
! {
int c = pg_input.read();
if (c 0)
throw new PSQLException(postgresql.stream.eof);
else if (c == 0) {
rst[s] = 0;
break;
! } else
rst[s++] = (byte)c;
}
! if (s = maxsiz)
! throw new PSQLException(postgresql.stream.toomuch);
} catch (IOException e) {
throw new PSQLException(postgresql.stream.ioerror,e);
}
String v = null;
if (encoding == null)
v = new String(rst, 0, s);
--- 201,245
}
/**
!* Receives a null-terminated string from the backend. If we don't see a
!* null, then we assume something has gone wrong.
*
* @param encoding the charset encoding to use.
* @return string from back end
!* @exception SQLException if an I/O error occurs, or end of file
*/
! public String ReceiveString(String encoding)
throws SQLException
{
int s = 0;
! byte[] rst = byte_buf;
! try {
! int buflen = rst.length;
! boolean done = false;
! while (!done) {
! while (s buflen) {
int c = pg_input.read();
if (c 0)
throw new PSQLException(postgresql.stream.eof);
else if (c == 0) {
rst[s] = 0;
+ done = true;
break;
! } else {
rst[s++] = (byte)c;
}
! if (s = buflen) { // Grow the buffer
! buflen = (int)(buflen*2); // 100% bigger
! byte[] newrst = new byte[buflen];
! System.arraycopy(rst, 0, newrst, 0, s);
! rst = newrst;
! }
! }
! }
} catch (IOException e) {
throw new PSQLException(postgresql.stream.ioerror,e);
}
+
String v = null;
if (encoding == null)
v = new String(rst, 0, s);
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
--
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 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] [PATCH] Cleanup of JDBC character encoding
Old removed. Your patch has been added to the PostgreSQL unapplied patches list at: http://candle.pha.pa.us/cgi-bin/pgpatches I will try to apply it within the next 48 hours. On Thu, 12 Jul 2001, Bruce Momjian wrote: Your patch has been added to the PostgreSQL unapplied patches list at: Here is a new version of that patch, with improvements from some feedback I got from Barry Lind. More of the encoding-related logic is moved into the Encoding class and I've added som clarifying comments. /Anders With this patch I've done an attempt to make the handling of character encoding in the JDBC driver a little clearer. * Cleans up the logic to select a JVM encoding for a backend encoding. * Makes the connection setup code easier to read. * Gathers character encoding and decoding in a single place. * Adds unit tests for encoding. * Introduces a new class, org.postgresql.core.Encoding, and the corresponding unit test class, org.postgresql.test.jdbc2.EncodingTest. _ A n d e r s B e n g t s s o n [EMAIL PROTECTED] Stockholm, Sweden Content-Description: [ Attachment, skipping... ] Content-Description: [ Attachment, skipping... ] Content-Description: [ Attachment, skipping... ] -- 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 4: Don't 'kill -9' the postmaster
Re: [JDBC] Connection.setCatalog()
OK, seems like this is the final one to be applied. Your patch has been added to the PostgreSQL unapplied patches list at: http://candle.pha.pa.us/cgi-bin/pgpatches I will try to apply it within the next 48 hours. [[[ Original Message from Tom Lane [EMAIL PROTECTED] ]]] Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: Peter E. has previously commented that Postgres databases correspond most closely to the SQL concept of catalog cluster, not catalog. I most certainly did not. According to my interpretation: I sit corrected. If you want to define catalog == database, okay with me. regards, tom lane Great, here is a context diff of CVS for implementing the get/setCatalog methods in Connection - note: I've updated setCatalog(String catalog) from my previous diff so it checks whether it is already connected to the specified catalog. Thanks, Jason Davies [EMAIL PROTECTED] [ Attachment, skipping... ] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [JDBC] DatabaseMetaData.getColumns() - default values
Your patch has been added to the PostgreSQL unapplied patches list at: http://candle.pha.pa.us/cgi-bin/pgpatches I will try to apply it within the next 48 hours. Hi, DatabaseMetaData.getColumns() doesn't appear to get the default value for each column. Here is a context diff of CVS which should fix it. Jason Davies [EMAIL PROTECTED] [ Attachment, skipping... ] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html -- 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: [PATCHES] Re: [JDBC] [PATCH] Cleanup of JDBC character encoding
Your patch has been added to the PostgreSQL unapplied patches list at: http://candle.pha.pa.us/cgi-bin/pgpatches I will try to apply it within the next 48 hours. On Sun, 15 Jul 2001, Bruce Momjian wrote: I am having trouble applying this patch to the current CVS tree. The majority of changes fail to apply. Can you give me a patch against current CVS or can someone manually merge the changes into CVS and send me a patch? Thanks. Here's a patch against the current CVS. The changes from the previous patch are mostly related to the changed interface for PG_Stream. /Anders _ A n d e r s B e n g t s s o n [EMAIL PROTECTED] Stockholm, Sweden Content-Description: [ Attachment, skipping... ] Content-Description: [ Attachment, skipping... ] Content-Description: [ Attachment, skipping... ] -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [JDBC] DatabaseMetaData.getColumns() - default values
Thanks. Patch applied. Hi, DatabaseMetaData.getColumns() doesn't appear to get the default value for each column. Here is a context diff of CVS which should fix it. Jason Davies [EMAIL PROTECTED] [ Attachment, skipping... ] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [JDBC] Connection.setCatalog()
Patch applied. Thanks. [[[ Original Message from Tom Lane [EMAIL PROTECTED] ]]] Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: Peter E. has previously commented that Postgres databases correspond most closely to the SQL concept of catalog cluster, not catalog. I most certainly did not. According to my interpretation: I sit corrected. If you want to define catalog == database, okay with me. regards, tom lane Great, here is a context diff of CVS for implementing the get/setCatalog methods in Connection - note: I've updated setCatalog(String catalog) from my previous diff so it checks whether it is already connected to the specified catalog. Thanks, Jason Davies [EMAIL PROTECTED] [ Attachment, skipping... ] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html -- 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
[JDBC] Re: [PATCHES] Merging JDBC1 and JDBC2 similarities
Patch applied. Thanks. This patch merges the identical methods from the JDBC1 and JDBC2 connection implementations (org.postgresql.jdbc[1|2].Connection) into their superclass (org.postgresql.Connection). It also changes the close() methods of Connection and PG_Stream, so that PG_Stream no longer is responsible for sending the termination packet 'X' to the backend. I figured that protocol-level stuff like that belonged in Connection more than in PG_Stream. /Anders _ A n d e r s B e n g t s s o n [EMAIL PROTECTED] Stockholm, Sweden Content-Description: [ Attachment, skipping... ] ---(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: [JDBC] Re: What needs to be done?
I actually consider the biggest problem the fact the the 'official' postgres jdbc website is very much out of date (http://jdbc.postgresql.org). (it doesn't even have the 7.1 drivers). I feel that either someone needs to maintain this page; or someone needs to create a new website and get the jdbc.postgresql.org DNS entry to point to the new site, or the page should just be decommisioned. At this point I think it is doing more harm than good. Just a followup. Peter has replied to a few people stating he is very busy and wants someone to take over the jdbc.postgresql.org website. Marc, Vince, and others are working on it now. -- 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 4: Don't 'kill -9' the postmaster
[JDBC] Re: Current cvs does not compile jdbc1 driver
I am confused. It compiles here. I don't understand this patch either. Can you send a context diff? Here is a quick hack to get it to compile properly Index: Connection.java === RCS file: /home/projects/pgsql/cvsroot/pgsql/src/interfaces/jdbc/org/postgresql/Co nnection.java,v retrieving revision 1.21 diff -f -r1.21 Connection.java c1039 1040 info.put(user, PG_USER); info.put(password, PG_PASSWORD); -- 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] Patch to improve commit time performance and a few otherthings
{
! return connection.haveMinimumServerVersion(6.4);
}
/**
***
*** 608,614
*/
public boolean supportsLikeEscapeClause() throws SQLException
{
! return haveMinimumServerVersion(7.1);
}
/**
--- 592,598
*/
public boolean supportsLikeEscapeClause() throws SQLException
{
! return connection.haveMinimumServerVersion(7.1);
}
/**
***
*** 749,755
*/
public boolean supportsOuterJoins() throws SQLException
{
! return haveMinimumServerVersion(7.1);
}
/**
--- 733,739
*/
public boolean supportsOuterJoins() throws SQLException
{
! return connection.haveMinimumServerVersion(7.1);
}
/**
***
*** 761,767
*/
public boolean supportsFullOuterJoins() throws SQLException
{
! return haveMinimumServerVersion(7.1);
}
/**
--- 745,751
*/
public boolean supportsFullOuterJoins() throws SQLException
{
! return connection.haveMinimumServerVersion(7.1);
}
/**
***
*** 976,982
*/
public boolean supportsSelectForUpdate() throws SQLException
{
! return haveMinimumServerVersion(6.5);
}
/**
--- 960,966
*/
public boolean supportsSelectForUpdate() throws SQLException
{
! return connection.haveMinimumServerVersion(6.5);
}
/**
***
*** 1053,1059
*/
public boolean supportsCorrelatedSubqueries() throws SQLException
{
! return haveMinimumServerVersion(7.1);
}
/**
--- 1037,1043
*/
public boolean supportsCorrelatedSubqueries() throws SQLException
{
! return connection.haveMinimumServerVersion(7.1);
}
/**
***
*** 1075,1081
*/
public boolean supportsUnionAll() throws SQLException
{
! return haveMinimumServerVersion(7.1);
}
/**
--- 1059,1065
*/
public boolean supportsUnionAll() throws SQLException
{
! return connection.haveMinimumServerVersion(7.1);
}
/**
***
*** 1303,1309
*/
public int getMaxRowSize() throws SQLException
{
! if (haveMinimumServerVersion(7.1))
return 1073741824;// 1 GB
else
return 8192; // XXX could be altered
--- 1287,1293
*/
public int getMaxRowSize() throws SQLException
{
! if (connection.haveMinimumServerVersion(7.1))
return 1073741824;// 1 GB
else
return 8192; // XXX could be altered
***
*** 1329,1335
*/
public int getMaxStatementLength() throws SQLException
{
! if (haveMinimumServerVersion(7.0))
return 0; // actually whatever fits in size_t
else
return 16384;
--- 1313,1319
*/
public int getMaxStatementLength() throws SQLException
{
! if (connection.haveMinimumServerVersion(7.0))
return 0; // actually whatever fits in size_t
else
return 16384;
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go 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 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: [PATCHES] JDBC Statement cleanup patch
Your patch has been added to the PostgreSQL unapplied patches list at: http://candle.pha.pa.us/cgi-bin/pgpatches I will try to apply it within the next 48 hours. Hello, Attached is a patch to remove some redundant code in the JDBC driver. * Merges identical code from org.postgresql.jdbc[1|2].Statement into org.postgresql.Statement. * Moves escapeSQL() method from Connection to Statement (the only place it's used) * Minor cleanup of the new isolation level stuff. * Minor cleanup of version string handling. /Anders _ A n d e r s B e n g t s s o n [EMAIL PROTECTED] Stockholm, Sweden Content-Description: [ Attachment, skipping... ] ---(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 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[JDBC] Re: [PATCHES] JDBC2 Array Patch (New feature)
Patch rejected. Please update with jdbc suggestions and resubmit. Hello... This is my first contribution for Postgresql, so I hope its found the proper home. The patch adds Array support to the JDBC2 library (to myknowledge Arrays aren't part of JDBC 1.0(?)). Specifically you can now use the ResultSet.getArray() method to return an java.sql.Array object. Its a really convenient way to load up a Java array with one columns' worth of results. It is mostly implemented, except for a few less common data types that I wasn't sure how to correctly pack into the tuples. The JDBC Array method variants that use type Map objects are likewise unsupported because the corresponding code in ResultSet has yet to be enabled. Other than that its all there. The patch is for the 7.1.2 latest build. I tried building the snapshot build but for some reason it wouldn't compile for me, so the latest was the best available. To apply the patch: cd to postgresql_src_dir/src/interfaces/jdbc/org/postgresql patch -p1 /PATH_TO_PATCH_FILE/patch.txt cd ../.. ant This will build the new postgresql.jar in the jars directory. Please forward any comments to [EMAIL PROTECTED] Thanks Greg Zoller ps. I would be very grateful if the owner/maintainer of the JDBC interface would fire off a short email to tell me if my Array code is worthy of inclusion in the next Postgresql release! _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp [ Attachment, skipping... ] ---(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 -- 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 4: Don't 'kill -9' the postmaster
Re: [PATCHES] Re: [JDBC] JDBC pg_description update needed for CVS tip
Applied. Thanks. Attached is the patch requested by Tom Lane (see below). It includes two changes in the JDBC driver: 1) When connected to a backend = 7.2: use obj_description() and col_description() instead of direct access to pg_description. 2) In DatabaseMetaData.getTables()/getColumns()/getProcedures(): when there is no comment on the object, return null in the REMARKS column of the ResultSet, instead of the default string no remarks. Change 2 first appeared as a side-effect of change 1, but it is actually more compliant with the JDBC spec: String object containing an explanatory comment on the table/column/procedure, which may be null. The default string no remarks was strictly speaking incorrect, as it could not be distinguished from a real user comment no remarks. So I removed the default string completely. Change 2 might break existing code that doesn't follow the JDBC spec and isn't prepared to handle a null in the REMARKS column of getTables()/getColumns()/getProcedures. Patch tested with jdbc2 against both a 7.1 and a CVS tip backend. I did not have a jdbc1 environment to build and test with, but since the touched code is identical in jdbc1 and jdbc2 I don't foresee any problems. Regards, Ren? Pijlman On Fri, 10 Aug 2001 16:08:50 -0400, Tom Lane wrote: Would some JDBC hacker develop a patch for the following issue? The change is just barely large enough that I don't want to commit untested code for it --- but not having a Java development environment at hand, I can't test the updated code. The problem is in DatabaseMetaData.java (same code in both jdbc1 and jdbc2, looks like). It does direct access to pg_description that isn't right anymore. In getTables, instead of java.sql.ResultSet dr = connection.ExecSQL(select description from pg_description where objoid=+r.getInt(2)); it should be java.sql.ResultSet dr = connection.ExecSQL(select obj_description(+r.getInt(2)+,'pg_class')); In getColumns, the change is a little more involved, because pg_attribute doesn't have an OID column anymore. The initial query can't fetch a.oid, but should fetch a.attrelid instead, and then the pg_description query should become java.sql.ResultSet dr = connection.ExecSQL(select col_description(+r.getInt(1)+,+r.getInt(5)+)); (col_description takes the table OID and the column's attnum). The reason this is more than a 3-line change is that it should be done either the old way or the new way depending on whether server version = 7.2 or not, for backwards-compatibility of the driver. It's possible there are other similar changes needed that I missed in a quick lookover. So, would some enterprising person fix the JDBC code to work with CVS tip, and submit a patch? thanks, tom lane ---(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 Regards, Ren? Pijlman [ Attachment, skipping... ] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [JDBC] Couple of patches for jdbc driver
-- Start of PGP signed section. I guess my question is, when I submitted the patches after 7.1.2 was released, I was hoping they would be in the next release, 7.1.3 Is there a way for my patches to make it into the next release, which I assume is 7.2? Or, is the current source-tree geared for 7.2 all-along? Good question. We froze jdbc around February 2001 for 7.1.X. At that time, our main jdbc maintainer wasn't available and we didn't have enough jdbc testers to add stuff during the beta period. This issue came up recently in relation to backpatching a python fix, and the conclusion was that jdbc 7.1.X is a hopeless cause and I tend to agree. I had 6 unapplied jdbc patches at the time we released 7.1. They are all now in CVS. Anyone who reports a jdbc problem is encourage to download the CVS JAR at: http://jdbc.fastcrypt.com 7.2 will be different because we now have an active jdbc community of coders and testers. Also, keep in mind most patches aren't backpatched for reliability reasons. -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [JDBC] Re: [PATCHES] Array Support Fix
Bruce, I just checked out the source from cvs and it compiles the version 2 drivers fine. Version 1 drivers need some work.. Yes, it compiles now fine too. Must have been that last patch that fixed it. -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [JDBC] Re: Couple of patches for jdbc driver
The other reason for telling people who are experiencing problems with the driver to get the latest version is that their bug has probably already been fixed. However a certain degree of caution should probably be exercised here. The real problem is that I don't remember all the things we have fixed in jdbc since 7.1.2 version so I am telling people to get the CVS version even if I am not sure it is fixed in there. -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [JDBC] Re: Couple of patches for jdbc driver
Quoting Bruce Momjian [EMAIL PROTECTED]: The other reason for telling people who are experiencing problems with the driver to get the latest version is that their bug has probably already been fixed. However a certain degree of caution should probably be exercised here. The real problem is that I don't remember all the things we have fixed in jdbc since 7.1.2 version so I am telling people to get the CVS version even if I am not sure it is fixed in there. Isn't the changelog kept up to date anymore? Uh, CHANGELOG? :-) No, I haven't been doing that, figuring I would update it in the main release notes. However, I haven't started doing that yet, and in fact I don't think I know enough about jdbc to know how to describe the items. I am relying on my compile tests and the jdbc list members for assistance with patch evaluation. -- 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 4: Don't 'kill -9' the postmaster
Re: [JDBC] Re: Couple of patches for jdbc driver
Bruce, I can try to fill in whatever I can. Where is it? Can you fill in as much as you can? Uh, there is a CHANGELOG file in the top level jdbc directory. We usually don't list interface-specific changes in the release notes. Instead we update a CHANGELOG file in the directory for that interface. Can you do a 'cvs log' of the jdbc directory and update that file? Don't worry about the date because this will all be in 7.2. -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [JDBC] Re: [BUGS] Bug #428: Another security issue with the JDBCdriver.
Patch reversed. Please advise how to continue.
Please pull this patch. It breaks JDBC1 support. The JDBC1 code no
longer compiles, due to objects being referenced in this patch that do
not exist in JDK1.1.
thanks,
--Barry
[copy] Copying 1 file to
/home/blind/temp/pgsql/src/interfaces/jdbc/org/postgresql
[echo] Configured build for the JDBC1 edition driver
compile:
[javac] Compiling 38 source files to
/home/blind/temp/pgsql/src/interfaces/jdbc/build
[javac]
/home/blind/temp/pgsql/src/interfaces/jdbc/org/postgresql/PG_Stream.java:33:
Interface org.postgresql.PrivilegedExceptionAction of nested class
org.postgresql.PG_Stream. PrivilegedSocket not found.
[javac] implements PrivilegedExceptionAction
[javac] ^
[javac]
/home/blind/temp/pgsql/src/interfaces/jdbc/org/postgresql/PG_Stream.java:63:
Undefined variable or class name: AccessController
[javac] connection = (Socket)AccessController.doPrivileged(ps);
[javac] ^
[javac]
/home/blind/temp/pgsql/src/interfaces/jdbc/org/postgresql/PG_Stream.java:65:
Class org.postgresql.PrivilegedActionException not found in type
declaration.
[javac] catch(PrivilegedActionException pae){
[javac]^
[javac] 3 errors
BUILD FAILED
Bruce Momjian wrote:
Patch applied. Thanks.
I am sorry to keep going back and forth on this, but:
The original patch is correct and does the proper thing. I should have
tested this before sounding the alarm.
AccessController.doPrivileged()
Propagates SecurityExceptions without wrapping them in a PrivilegedActionException
so it appears that there is not the possibility of a ClassCastException.
David Daney.
Bruce Momjian wrote:
OK, patch removed from queue.
It is now unclear to me the the
catch(PrivilegedActionException pae)
part of the patch is correct. If a SecurityException is thrown in
Socket() (as might happen if the policy file did not give the proper
permissions), then it might be converted into a ClassCastException,
which is probably the wrong thing to do.
Perhaps I should look into this a bit further.
David Daney.
Bruce Momjian wrote:
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
David Daney ([EMAIL PROTECTED]) reports a bug with a severity of 3
The lower the number the more severe it is.
Short Description
Another security issue with the JDBC driver.
Long Description
The JDBC driver requires
permission java.net.SocketPermission host:port, connect;
in the policy file of the application using the JDBC driver
in the postgresql.jar file. Since the Socket() call in the
driver is not protected by AccessController.doPrivileged() this
permission must also be granted to the entire application.
The attached diff fixes it so that the connect permission can be
restricted just the the postgresql.jar codeBase if desired.
Sample Code
*** PG_Stream.java.orig Fri Aug 24 09:27:40 2001
--- PG_Stream.java Fri Aug 24 09:42:14 2001
***
*** 5,10
--- 5,11
import java.net.*;
import java.util.*;
import java.sql.*;
+ import java.security.*;
import org.postgresql.*;
import org.postgresql.core.*;
import org.postgresql.util.*;
***
*** 27,32
--- 28,52
BytePoolDim1 bytePoolDim1 = new BytePoolDim1();
BytePoolDim2 bytePoolDim2 = new BytePoolDim2();
+private static class PrivilegedSocket
+ implements PrivilegedExceptionAction
+{
+ private String host;
+ private int port;
+
+ PrivilegedSocket(String host, int port)
+ {
+ this.host = host;
+ this.port = port;
+ }
+
+ public Object run() throws Exception
+ {
+ return new Socket(host, port);
+ }
+}
+
+
/**
* Constructor: Connect to the PostgreSQL back end and return
* a stream connection.
***
*** 37,43
*/
public PG_Stream(String host, int port) throws IOException
{
! connection = new Socket(host, port);
// Submitted by Jason Venner [EMAIL PROTECTED] adds a 10x speed
// improvement on FreeBSD machines (caused by a bug in their TCP Stack)
--- 57,69
*/
public PG_Stream(String host, int port) throws IOException
{
! PrivilegedSocket ps = new PrivilegedSocket(host, port);
! try {
! connection = (Socket)AccessController.doPrivileged(ps);
! }
! catch(PrivilegedActionException pae){
! throw (IOException)pae.getException();
! }
// Submitted by Jason Venner [EMAIL PROTECTED] adds a 10x speed
// improvement on FreeBSD machines (caused by a bug in their TCP Stack)
No file was uploaded
Re: [JDBC] Re: Proposal to fix Statement.executeBatch()
No problem. Just checking. Patch will remain in the queue and be applied. Bruce, I think the existing patch can be applied as is. The issues I raised below are further improvements in the functionality that can be done and don't directly relate to the patch that was submitted. Sorry if I confused things. --Barry Bruce Momjian wrote: Can someone suggest what is to be done with the propsed patch? What exactly is the behaviour of the backend in that scenario? Does it commit every separate SQL statement in the semicolon-separated list, or does it commit the list as a whole? Does it abort processing the statement list when an error occurs in one statement? And if it continues, does it return an error when only one statement in the middle of the list had an error? I do not know what the server does if you have autocommit enabled and you issue multiple statements in one try. However, I would be OK with the driver issuing the statements one by one with autocommit on. If you are running in this mode you just wouldn't get any performance improvement. However, it would mean a change in behaviour of the driver that may break existing JDBC applications: the driver will no longer return update counts for all statements in a batch like it currently does, it will return unknown for most statements. I'm not sure if the performance improvement justifies this non-backwardly-compatible change, though I agree this is the intention of the feature. What do you think? I wouldn't worry about this 'change in behavior' because if the caller is JDBC complient it should be coded to handle the new behavior as it is complient with the spec. thanks, --Barry Rene Pijlman wrote: On Mon, 27 Aug 2001 11:07:55 -0700, you wrote: [executeBatch() implemented as one round trip] Here is how I would suggest this be done in a way that is spec compliant (Note: that I haven't looked at the patch you submited yet, so forgive me if you have already done it this way, but based on your comments in this email, my guess is that you have not). Indeed, I have not implemented this. Statements should be batched together in a single statement with semicolons separating the individual statements (this will allow the backend to process them all in one round trip). The result array should return an element with the row count for each statement, however the value for all but the last statement will be '-2'. (-2 is defined by the spec to mean the statement was processed successfully but the number of affected rows is unknown). Ah, I see. I hadn't thought of that solution. In the event of an error, then the driver should return an array the size of the submitted batch with values of -3 for all elements. -3 is defined by the spec as the corresponding statement failed to execute successfully, or for statements that could not be processed for some reason. Since in postgres when one statement fails (in non-autocommit mode), the entire transaction is aborted this is consistent with a return value of -3 in my reading of the spec. Not quite. A statement in a batch may also fail because its a succesful SELECT as far as the server is concerned (can't have select's in a batch). But that situation can also be handled correctly by setting the update count for that particular statement to -3. Its then up to the application to decide if it wants to rollback, I would say. But what to do when an error occurs with autocommit enabled? This is not recommended, but allowed by the spec, if I understand it correctly. What exactly is the behaviour of the backend in that scenario? Does it commit every separate SQL statement in the semicolon-separated list, or does it commit the list as a whole? Does it abort processing the statement list when an error occurs in one statement? And if it continues, does it return an error when only one statement in the middle of the list had an error? I believe this approach makes the most sense because: 1) It implements batches in one round trip (the intention of the feature) 2) It is complient with the standard 3) It is complient with the current functionality of the backend If we can come up with an acceptable solution for an error with autocommit enabled, I agree. Otherwise, I'm not sure. However, it would mean a change in behaviour of the driver that may break existing JDBC applications: the driver will no longer return update counts for all statements in a batch like it currently does, it will return unknown for most statements. I'm not sure if the performance improvement justifies this non-backwardly-compatible change, though I agree this is the intention of the feature. What do you think? Regards, Ren? Pijlman ---(end of broadcast)--- TIP 3: if posting/reading through Usenet
[JDBC] Re: [PATCHES] patch for JDBC1 build problems
Types.NUMERIC:
Field f = getField(column);
if(f != null)
! return (((0x)f.getMod())-4);
else
return 0;
default:
***
*** 384,390
*/
public String getColumnTypeName(int column) throws SQLException
{
! return getField(column).getTypeName();
}
/**
--- 384,390
*/
public String getColumnTypeName(int column) throws SQLException
{
! return getField(column).getPGType();
}
/**
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
--
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 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] [PATCHES] Patch for broken JDBC's getColumn()
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
Hi,
Attached is a patch for JDBC's getColumn() function that was broken /
flawed in the following ways:
1. Only returned columns that had a default value defined, rather than all
columns in a table
2. Used 2 * N + 1 queries to find out attributes, comments and typenames
for N columns.
By using some outer join syntax it is possible to retrieve all necessary
information in just one SQL statement. This means this version is only
suitable for PostgreSQL = 7.1. Don't know whether that's a problem.
I've tested this function with current sources and 7.1.3 and patched both
jdbc1 and jdbc2. I haven't compiled nor tested the jdbc1 version though, as
I have no JDK 1.1 available.
Note the discussion in http://fts.postgresql.org/db/mw/msg.html?mid=1029626
regarding differences in obtaining comments on database object in 7.1 and
7.2. I was unable to use the following syntax (or similar ones):
select
...,
description
from
...
left outer join col_description(a.attrelid, a.attnum) description
order by
c.relname, a.attnum;
(the error was parse error at or near '(') so I had to paste the actual
code for the col_description function into the left outer join. Maybe
someone who is more knowledgable about outer joins might provide me with a
better SQL statement.
Please review.
Regards,
Jeroen
[ Attachment, skipping... ]
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go 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 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [JDBC] Re: Unterminated quoted string error.
I have added a description to the CVS and it will appear in 7.2. It is in the development docs now. Hi Barry, I looked in the postgresql documentation and couldn't find any mention of a bytea type. Well actually, I found .. $ grep -i bytea * bki-commands.html:bytea/TT catalog-pg-proc.html:bytea/TT xfunc-c.html:bytea/TD xfunc-c.html:(bytea *)/TD but no real info on what it is, or no mention of it in the main types page. Anyway, I think I'm fine for now, stipping the null chars from my data. Tom. On Tue, Aug 28, 2001 at 09:17:19PM -0700, Barry Lind wrote: Thomas, The text datatypes in postgres (i.e. char, varchar, text) do not support storing null characters. If your data contains nulls then you need to use the binary datatype bytea. Unfortunately the JDBC drivers do not currently support the bytea datatype. thanks, --Barry Thomas O'Dowd wrote: I found problem. My string has a null character in the middle of it. I noticed from the Connection.java code that the null character idicates end of query so I guess that is what is happening. I'll strip out my null strings in the mean time as they are not needed before sending them to the driver but I'm wondering if the preparedStatement.setString() shouldn't escape nulls or something. It already escapes single quotes and backslashes. What do people think? Cheers, Tom. On Wed, Aug 29, 2001 at 08:53:31AM +0900, Thomas O'Dowd wrote: Thanks Barry, I turned on debugging in postgresql. I found that the query is being truncated and is not fully making it to the backend, therefore I'm getting the Unterminated string error. I'll have a look into why and report back if I find anything. Cheers, Tom. On Tue, Aug 28, 2001 at 12:56:50PM -0700, Barry Lind wrote: Thomas, If you turn on debug messages on the server to print out the SQL statements it receives you should be able to get the exact string that the server is receiving from the client and failing on. That might help you find the problem. thanks, --Barry Thomas O'Dowd wrote: Hi all, I'm currently chasing down a bug. Wonder if anyone can throw some light on it. I get the following exception. An I/O error has occured while flushing the output - Exception: java.io.IOException: Connection reset by peer Stack Trace: java.io.IOException: Connection reset by peer at java.net.SocketOutputStream.socketWrite(Native Method) at java.net.SocketOutputStream.write(SocketOutputStream.java:83) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:72) at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:130) at org.postgresql.PG_Stream.flush(PG_Stream.java:414) at org.postgresql.Connection.ExecSQL(Connection.java:479) at org.postgresql.jdbc2.Statement.execute(Statement.java:294) at org.postgresql.jdbc2.Statement.executeUpdate(Statement.java:78) at org.postgresql.jdbc2.PreparedStatement.executeUpdate(PreparedStatement.java:122) And in the postgresql.log file I get... ERROR: Unterminated quoted string FATAL 1: Socket command type unknown But I'm pretty sure that my strings are quoted properly. That is to say that there are about 90 escaped single quotes in a string I'm inserting also though. Anyone seen this before? I'm currently using a version of the driver that I compiled from cvs on the 18th of Jun. Was anything patched since that might effect this? Anyway, I've been digging around for quite a while now so I thought I'd shoot the list a mail before going to bed. Tom. -- Thomas O'Dowd. - Nooping - http://nooper.com [EMAIL PROTECTED] - Testing - http://nooper.co.jp/labs ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Thomas O'Dowd. - Nooping - http://nooper.com [EMAIL PROTECTED] - Testing - http://nooper.co.jp/labs ---(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 4: Don't 'kill -9' the postmaster
Re: [JDBC] Re: Unterminated quoted string error.
I heard it was fixed too but looking around, I found nothing. I added it tonight to the types section. Thomas, You are correct about the poor documentation for bytea. I hear this is fixed in 7.2 docs, but haven't verified. I learned about it myself by looking at the internal pg_* tables and seeing how they used it. I'm glad to hear that you have a workaround for your original issue. thanks, --Barry Thomas O'Dowd wrote: Hi Barry, I looked in the postgresql documentation and couldn't find any mention of a bytea type. Well actually, I found .. $ grep -i bytea * bki-commands.html:bytea/TT catalog-pg-proc.html:bytea/TT xfunc-c.html:bytea/TD xfunc-c.html:(bytea *)/TD but no real info on what it is, or no mention of it in the main types page. Anyway, I think I'm fine for now, stipping the null chars from my data. Tom. On Tue, Aug 28, 2001 at 09:17:19PM -0700, Barry Lind wrote: Thomas, The text datatypes in postgres (i.e. char, varchar, text) do not support storing null characters. If your data contains nulls then you need to use the binary datatype bytea. Unfortunately the JDBC drivers do not currently support the bytea datatype. thanks, --Barry Thomas O'Dowd wrote: I found problem. My string has a null character in the middle of it. I noticed from the Connection.java code that the null character idicates end of query so I guess that is what is happening. I'll strip out my null strings in the mean time as they are not needed before sending them to the driver but I'm wondering if the preparedStatement.setString() shouldn't escape nulls or something. It already escapes single quotes and backslashes. What do people think? Cheers, Tom. On Wed, Aug 29, 2001 at 08:53:31AM +0900, Thomas O'Dowd wrote: Thanks Barry, I turned on debugging in postgresql. I found that the query is being truncated and is not fully making it to the backend, therefore I'm getting the Unterminated string error. I'll have a look into why and report back if I find anything. Cheers, Tom. On Tue, Aug 28, 2001 at 12:56:50PM -0700, Barry Lind wrote: Thomas, If you turn on debug messages on the server to print out the SQL statements it receives you should be able to get the exact string that the server is receiving from the client and failing on. That might help you find the problem. thanks, --Barry Thomas O'Dowd wrote: Hi all, I'm currently chasing down a bug. Wonder if anyone can throw some light on it. I get the following exception. An I/O error has occured while flushing the output - Exception: java.io.IOException: Connection reset by peer Stack Trace: java.io.IOException: Connection reset by peer at java.net.SocketOutputStream.socketWrite(Native Method) at java.net.SocketOutputStream.write(SocketOutputStream.java:83) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:72) at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:130) at org.postgresql.PG_Stream.flush(PG_Stream.java:414) at org.postgresql.Connection.ExecSQL(Connection.java:479) at org.postgresql.jdbc2.Statement.execute(Statement.java:294) at org.postgresql.jdbc2.Statement.executeUpdate(Statement.java:78) at org.postgresql.jdbc2.PreparedStatement.executeUpdate(PreparedStatement.java:122) And in the postgresql.log file I get... ERROR: Unterminated quoted string FATAL 1: Socket command type unknown But I'm pretty sure that my strings are quoted properly. That is to say that there are about 90 escaped single quotes in a string I'm inserting also though. Anyone seen this before? I'm currently using a version of the driver that I compiled from cvs on the 18th of Jun. Was anything patched since that might effect this? Anyway, I've been digging around for quite a while now so I thought I'd shoot the list a mail before going to bed. Tom. -- Thomas O'Dowd. - Nooping - http://nooper.com [EMAIL PROTECTED] - Testing - http://nooper.co.jp/labs ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [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 -- 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: [JDBC] Re: Escape Processing problems
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
Hmmm, after a little more testing, I fixed a problem with backslashes.
New code attached.
Tom.
On Thu, Aug 30, 2001 at 11:46:16AM +0900, Thomas O'Dowd wrote:
Hi all,
I found some time this morning to write and test a new EscapeSQL() method.
I didn't make a patch for the driver yet as I'd like to hear some
comments. It's a tad longer than the original code as it only replaces
escape codes which appear in the SQL code and not inside strings.
It's attached as a separate java program which you can run to test with
various strings. Let me know if you think it is okay. It seems to work
with what I've tested it with.
Example:
$ /usr/local/java/jdk1.3/bin/java esc insert into test values ({d '2000-12-01'},
'string of\\ \' {d }', {t '12:12:12'})
insert into test values ( '2000-12-01', 'string of\\ \' {d }', {t '12:12:12'})
Do you think we should expand it to handle the other codes like {t and {ts ?
The old routine only handles {d.
Tom.
--
Thomas O'Dowd. - Nooping - http://nooper.com
[EMAIL PROTECTED] - Testing - http://nooper.co.jp/labs
[ Attachment, skipping... ]
---(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 4: Don't 'kill -9' the postmaster
Re: [JDBC] Re: Escape Processing problems
Patch removed at request of author. Will resubmit.
Hmmm, after a little more testing, I fixed a problem with backslashes.
New code attached.
Tom.
On Thu, Aug 30, 2001 at 11:46:16AM +0900, Thomas O'Dowd wrote:
Hi all,
I found some time this morning to write and test a new EscapeSQL() method.
I didn't make a patch for the driver yet as I'd like to hear some
comments. It's a tad longer than the original code as it only replaces
escape codes which appear in the SQL code and not inside strings.
It's attached as a separate java program which you can run to test with
various strings. Let me know if you think it is okay. It seems to work
with what I've tested it with.
Example:
$ /usr/local/java/jdk1.3/bin/java esc insert into test values ({d '2000-12-01'},
'string of\\ \' {d }', {t '12:12:12'})
insert into test values ( '2000-12-01', 'string of\\ \' {d }', {t '12:12:12'})
Do you think we should expand it to handle the other codes like {t and {ts ?
The old routine only handles {d.
Tom.
--
Thomas O'Dowd. - Nooping - http://nooper.com
[EMAIL PROTECTED] - Testing - http://nooper.co.jp/labs
[ Attachment, skipping... ]
---(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 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] Read transactions don't work on 7.0.x db's Disregard my other
Your patch has been added to the PostgreSQL unapplied patches list at: http://candle.pha.pa.us/cgi-bin/pgpatches I will try to apply it within the next 48 hours. The first one considered everything changed ? I also fixed the rollback method in this one, assuming it was broken the same way Dave [ Attachment, skipping... ] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go 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 4: Don't 'kill -9' the postmaster
Re: [JDBC] driver source code indentation
I suggest that the JDBC driver adopt PostgreSQL's indentation standards (see PostgreSQL developers FAQ, question 1). I see that some source files have used this standard, but the vast majority do not. We should have a standard for consistency and our own sanity if nothing else. Glad someone brought this up. A while ago I wrote: I tried pgindent but it doesn't understand Java and made a mess of it. I used astyle with the options: $ astyle --style=java -j *.java I have the reformatted jdbc files at: ftp://candle.pha.pa.us/pub/postgresql/astyle_jdbc.tar.gz I must say it looks very good. Can people tak a look at that and see if they like it? I will work on astyle to find a format that matches the main code indenting. If you like it, I will indent just after we go beta. -- 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 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] Read transactions don't work on 7.0.x db's Disregard my other
Patch removed at Barry's request. The first one considered everything changed ? I also fixed the rollback method in this one, assuming it was broken the same way Dave [ Attachment, skipping... ] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go 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 4: Don't 'kill -9' the postmaster
Re: [JDBC] [PATCHES] Patch for jdbc2 ResultSet.java
Barry Lind wrote: Joseph, In looking at this patch it looks OK, except for the following change: ! if (index=-rows.size()) --- 725,737 ! if (index rows_size) I haven't looked at the entire method, but the change you made seems incorrect. Oops! Thanks for catching that. Cut and paste error. I hate those. If you want this patch to be applied it should be sent to the pgsql-patches mail list. I thought that jdbc stuff was preferred to be on the jdbc list. I guess not. Actually, yes, I throw stuff to jdbc and patches for completeness. jdbc people, tell me what you want done in the future. -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [JDBC] JDBC Statement.executeBatch patch
Patch applied and files added. Thanks. Attached is a patch for current CVS, consisting of a cvs diff -c for the changed files and a few new files: - test/jdbc2/BatchExecuteTest.java - util/MessageTranslator.java - jdbc2/PBatchUpdateException.java As an aside, is this the best way to submit a patch consisting of both changed and new files? Or is there a smarter cvs command which gets them all in one patch file? This patch fixes batch processing in the JDBC driver to be JDBC-2 compliant. Specifically, the changes introduced by this patch are: 1) Statement.executeBatch() no longer commits or rolls back a transaction, as this is not prescribed by the JDBC spec. Its up to the application to disable autocommit and to commit or rollback the transaction. Where JDBC talks about executing the statements as a unit, it means executing the statements in one round trip to the backend for better performance, it does not mean executing the statements in a transaction. 2) Statement.executeBatch() now throws a BatchUpdateException() as required by the JDBC spec. The significance of this is that the receiver of the exception gets the updateCounts of the commands that succeeded before the error occurred. In order for the messages to be translatable, java.sql.BatchUpdateException is extended by org.postgresql.jdbc2.PBatchUpdateException() and the localization code is factored out from org.postgresql.util.PSQLException to a separate singleton class org.postgresql.util.MessageTranslator. 3) When there is no batch or there are 0 statements in the batch when Statement.executeBatch() is called, do not throw an SQLException, but silently do nothing and return an update count array of length 0. The JDBC spec says Throws an SQLException if the driver does not support batch statements, which is clearly not the case. See testExecuteEmptyBatch() in BatchExecuteTest.java for an example. The message postgresql.stat.batch.empty is removed from the language specific properties files. 4) When Statement.executeBatch() is performed, reset the statement's list of batch commands to empty. The JDBC spec isn't 100% clear about this. This behaviour is only documented in the Java tutorial (http://java.sun.com/docs/books/tutorial/jdbc/jdbc2dot0/batchupdates.html). Note that the Oracle JDBC driver also resets the statement's list in executeBatch(), and this seems the most reasonable interpretation. 5) A new test case is added to the JDBC test suite which tests various aspects of batch processing. See the new file BatchExecuteTest.java. Regards, Ren? Pijlman [ Attachment, skipping... ] [ Attachment, skipping... ] [ Attachment, skipping... ] [ Attachment, skipping... ] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html -- 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] Fw: JDBC Patch italian errors.properties file
un'interfaccia.
postgresql.serial.namelength:La lunghezza dei nomi per Class Package non
pu? essere superiore a 32 caratteri. {0} ? di {1} caratteri.
postgresql.serial.noclass:Nessuna classe trovata per {0}.
postgresql.serial.table:La tabella per {0} non ? nel database. Contattare
l'amministratore del DB, visto che il database ? in uno stato incosistente.
postgresql.serial.underscore:Il nome di una classe non pu? contenere il
carattere ``_''. E` stato fornito {0}.
postgresql.stat.batch.empty:La sequenza di operazioni ? vuota. Non c'?
niente da eseguire.
postgresql.stat.batch.error:L'operazione {0} {1} della sequenza ? stata
annullata.
postgresql.stat.maxfieldsize:Fallito un tentativo a setMaxFieldSize() -
verr? utilizzato il valore predefinito a tempo di compilazione.
postgresql.stat.noresult:Nessun risultato ? stato restituito dalla query.
postgresql.stat.result:Un risultato ? stato restituito dallo statement,
quando non ci si aspettava nulla.
postgresql.stream.eof:Il backend ha interrotto la connessione. Probabilmente
la tua azione ha causato la sua uscita.
postgresql.stream.flush:Si ? verificato un errore di I/O mentre si svuotava
il buffer d'uscita - {0}
postgresql.stream.ioerror:Si ? verificato un errore di I/O mentre si
leggevano dati dal backend - {0}
postgresql.stream.toomuch:Troppi dati ricevuti.
postgresql.unusual:Qualcosa di insolito si ? verificato causando il
fallimento del driver. Per favore riferire all'autore del driver questa
eccezione: {0}
postgresql.unimplemented:Questo metodo non ? stato ancora implementato.
postgresql.unexpected:Un risultato inaspettato ? stato ricevuto dalla query.
--
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 4: Don't 'kill -9' the postmaster
Re: [JDBC] Attempt to clean up ExecSql() in JDBC
Patch applied and file added. Thanks. Hi, Attached is my attempt to clean up the horrors of the ExecSQL() method in the JDBC driver. I've done this by extracting it into a new method object called QueryExecutor (should go into org/postgresql/core/) and then taking it apart into different methods in that class. A short summary: * Extracted ExecSQL() from Connection into a method object called QueryExecutor. * Moved ReceiveFields() from Connection to QueryExecutor. * Extracted parts of the original ExecSQL() method body into smaller methods on QueryExecutor. * Bug fix: The instance variable pid in Connection was used in two places with different meaning. Both were probably in dead code, but it's fixed anyway. /Anders PS.: If anyone has any idea what the variable names fqp and hfr stand for, please tell me! :) _ A n d e r s B e n g t s s o n [EMAIL PROTECTED] Stockholm, Sweden Content-Description: [ Attachment, skipping... ] Content-Description: [ Attachment, skipping... ] ---(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 -- 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 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] error - NOTICE: current transaction...MORE DETAIL...
the 7.1 driver that i am using was downloaded from http://jdbc.fastcrypt.com. is that the right spot? Yep, that is the one. --- chris -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 06, 2001 12:40 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [JDBC] error - NOTICE: current transaction...MORE DETAIL... chris markiewicz [EMAIL PROTECTED] writes: i do agree that since everyone isn't complaining, the problem is likely in my code. the odd thing is that i wasn't seeing this behavior with the 7.0 stuff, only with the 7.1. Hmm. Are you using the JDBC driver that was released with 7.1? That seems to have been rather buggy. You might want to grab the latest version of the driver (I forget the URL but it's been mentioned repeatedly on this list). regards, tom lane ---(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 -- 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 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] Using char fields with 7.1.3 driver
I can easily get around this using .trim(), but I'm wondering if that should be in the jdbc driver itself (as I'll have to go through a bit of code looking for string values being returned). char() is fixed length, varchar isn't. Or is this something in the database software itself that you can configure? Also, Is there a real Website for the postgres jdbc driver? http://jdbc.postgresql.org seems a little outdated. I wouldn't mind being able to grab the source for the driver and putting in this small fix myself. http://jdbc.fastcrypt.com -- 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 4: Don't 'kill -9' the postmaster
Re: [JDBC] jdbc ResultSetMetaData::isWritable()
Well, if it is that easy, I can do it. Patch attached and applied.
On Mon, 3 Sep 2001 22:01:17 -0500, you wrote:
public boolean isWritable(int column) throws SQLException
{
if (isReadOnly(column))
return true;
else
return false;
}
The author probably intended:
public boolean isWritable(int column) throws SQLException
{
return !isReadOnly(column);
}
And if he would have coded it this way he wouldn't have made
this mistake :-)
hence, isWritable() will always return false. this is something
of a problem :)
Why exactly? In a way, true is just as incorrect as false, and
perhaps it should throw not implemented. But I guess that
would be too non-backwardly-compatible.
let me know if i can provide further information.
Will you submit a patch?
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
--
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
Index: src/interfaces/jdbc/org/postgresql/jdbc1/ResultSetMetaData.java
===
RCS file:
/home/projects/pgsql/cvsroot/pgsql/src/interfaces/jdbc/org/postgresql/jdbc1/ResultSetMetaData.java,v
retrieving revision 1.3
diff -c -r1.3 ResultSetMetaData.java
*** src/interfaces/jdbc/org/postgresql/jdbc1/ResultSetMetaData.java 2001/08/24
16:50:16 1.3
--- src/interfaces/jdbc/org/postgresql/jdbc1/ResultSetMetaData.java 2001/09/06
18:25:56
***
*** 419,428
*/
public boolean isWritable(int column) throws SQLException
{
! if (isReadOnly(column))
! return true;
! else
! return false;
}
/**
--- 419,425
*/
public boolean isWritable(int column) throws SQLException
{
! return !isReadOnly(column);
}
/**
Index: src/interfaces/jdbc/org/postgresql/jdbc2/ResultSetMetaData.java
===
RCS file:
/home/projects/pgsql/cvsroot/pgsql/src/interfaces/jdbc/org/postgresql/jdbc2/ResultSetMetaData.java,v
retrieving revision 1.3
diff -c -r1.3 ResultSetMetaData.java
*** src/interfaces/jdbc/org/postgresql/jdbc2/ResultSetMetaData.java 2001/08/24
16:50:18 1.3
--- src/interfaces/jdbc/org/postgresql/jdbc2/ResultSetMetaData.java 2001/09/06
18:25:56
***
*** 414,423
*/
public boolean isWritable(int column) throws SQLException
{
! if (isReadOnly(column))
! return true;
! else
! return false;
}
/**
--- 414,420
*/
public boolean isWritable(int column) throws SQLException
{
! return !isReadOnly(column);
}
/**
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Re: [JDBC] JDBC patch procedures (Re: [PATCHES] Patch for jdbc2 ResultSet.java)
On Thu, 06 Sep 2001 14:30:49 -0400, you wrote: Ultimately it's the committer's responsibility to have confidence that the patch he applies is good; if he doesn't feel competent to check it himself, he should call for more reviewers. If he does feel sure about it, there's no need for procedural overhead. Agreed. If the committer is in the team of certified reviewers and is willing to review patches, our procedures are basically the same. Any committing assistance would be greatly appreciated, especially for jdbc. -- 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: [JDBC] jdbc ResultSetMetaData::isWritable()
Change applied. Thanks.
On Thu, 6 Sep 2001 14:26:49 -0400 (EDT), you wrote:
Well, if it is that easy, I can do it. Patch attached and applied.
On Mon, 3 Sep 2001 22:01:17 -0500, you wrote:
public boolean isWritable(int column) throws SQLException
{
return !isReadOnly(column);
}
Actually, I think this change has a consequence for this method
in the same class:
public boolean isDefinitelyWritable(int column)
throws SQLException
{
return isWritable(column);
}
This is from the JDBC spec
(http://java.sun.com/j2se/1.3/docs/api/java/sql/ResultSetMetaData.html):
isReadOnly() - Indicates whether the designated column is
definitely not writable.
isWritable() - Indicates whether it is possible for a write on
the designated column to succeed.
isDefinitelyWritable() - Indicates whether a write on the
designated column will definitely succeed.
At this time we don't really implement the fine semantics of
these methods. I would suggest the following defaults:
isReadOnly() false
isWritable() true
isDefinitelyWritable() false
And that would mean that your patch is correct, but
isDefinitelyWritable() would need to be patched accordingly:
public boolean isDefinitelyWritable(int column)
throws SQLException
{
return false;
}
Again, both in jdbc1 and jdbc2.
Regards,
Ren? Pijlman [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 4: Don't 'kill -9' the postmaster
Re: [JDBC] Fix for 2 test cases of JDBC test suite
Patch applied. Thanks. Attached is a patch that fixes 2 test cases of the JDBC test suite. This reduces the number of failures from 9 to 7. Both ConnectionTest and JBuilderTest did not create their own tables, which caused these test cases to fail with relation ... does not exist. It appears these test cases relied on tables created by the example code elsewhere in the source tree. I've added the necessary create table and drop table statements to the test cases, using the column definitions from the example code. While working on that I modified the helper method createTable in JDBC2Tests.java to take a table parameter, rather than using table names passed via the properties in build.xml. I'm not sure what that was good for, and in fact, except for the default table name jdbctest, this functionality wasn't used at all. Regards, Ren? Pijlman [EMAIL PROTECTED] [ Attachment, skipping... ] ---(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 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] Read transactions don't work on 7.0.x db's 3rd attempt
Your patch has been added to the PostgreSQL unapplied patches list at: http://candle.pha.pa.us/cgi-bin/pgpatches I will try to apply it within the next 48 hours. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Dave Cramer Sent: September 4, 2001 1:21 PM To: [EMAIL PROTECTED] Subject: Re: [JDBC] Read transactions don't work on 7.0.x db's 2nd patch Here is a revised patch with Barry's suggestions implemented Dave [ Attachment, skipping... ] ---(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 4: Don't 'kill -9' the postmaster
Re: [JDBC] JDBC patch procedures (Re: [PATCHES] Patch for jdbc2 ResultSet.java)
Thanks for the votes of confidence. I am willing to take on the responsibility if the core committee agrees. Yes, we do. We don't know Java very well and are struggling. It would be nice to have someone who actually know the language applying the patches. :-) -- 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 4: Don't 'kill -9' the postmaster
Re: [JDBC] Fix JDBC test suite, set/get transaction isolation level
an SQLException. The DatabaseMetaData method supportsTransactionIsolationLevel may be used to determine whether or not the driver supports a given level. -+-+- Regards, Ren? Pijlman ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl [ Attachment, skipping... ] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go 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 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [JDBC] Patch for jdbc2 ResultSet.java
Can I have a new version of this for application? Dave Harkness wrote: At 12:41 PM 9/5/2001, Joseph Shraibman wrote: new patch: There still seems to be an error with the same if-block. ! if (index=-rows.size()) ! internalIndex=rows.size()+index; becomes ! if (index -rows_size) ! internalIndex = rows_size+index; Note that the original used =, not . Argh! I need a better screen. :( Also, why is the first edit being done? Granted it's faster in that it doesn't null out the array of rows, but won't that have other effects? No. Nulling out the array is pointless. -- Joseph Shraibman [EMAIL PROTECTED] Increase signal to noise ratio. http://www.targabot.com ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [JDBC] PostgreSQL/JDBC Test Suite Howto
I have added this to the jdbc source tree as TESTSUITE. Bruce, I posted this a couple of days ago on pgsql-patches and haven't seen a reply, and if I'm not mistaken the file is not in current CVS. Maybe my posting was overlooked. -+-+- I've written a brief Howto document about the JDBC test suite that's in the source tree. Liam Stewart contributed a section on the standard JDBC 2 test suite from Sun. Hopefully, this will make it easier for developers working on the JDBC driver to use and extend the test suite(s) to improve the quality of the driver. I suggest to add this document to the source tree as src/interfaces/jdbc/org/postgresql/test/README. I don't think it should be in the binary distribution. I hope my english in this document is OK. Please feel free to improve it. That's probably easiest to do as a patch once its in CVS. Regards, Ren? Pijlman [EMAIL PROTECTED] [ Attachment, skipping... ] -- 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 4: Don't 'kill -9' the postmaster
Re: [JDBC] [PATCHES] Patch for jdbc2 ResultSet.java
} } } - --- 1485,1487 -- Joseph Shraibman [EMAIL PROTECTED] Increase signal to noise ratio. http://www.targabot.com ---(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 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 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
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] Fix DatabaseMetaDataTest in JDBC test suite
Your patch has been added to the PostgreSQL unapplied patches list at: http://candle.pha.pa.us/cgi-bin/pgpatches I will try to apply it within the next 48 hours. 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] [ Attachment, skipping... ] ---(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 -- 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] [HACKERS] JDBC pg_description update needed for CVS tip
Patch applied. Thanks. On Fri, 07 Sep 2001 01:34:46 -0400, Tom Lane wrote: there is still an unpatched reference to pg_description in getColumns(), in both jdbc1 and jdbc2. This was introduced by Jeroen's patch (see http://fts.postgresql.org/db/mw/msg.html?mid=1032468). Attached is a patch that returns getColumns() to using select obj_description() instead of direct access to pg_description, as per the request by Tom. I've incorporated Jeroen's fix to left outer join with pg_attrdef instead of inner join, so getColumns() also returns columns without a default value. I have, however, not included Jeroen's attempt to combine multiple queries into one huge multi-join query for better performance, because: 1) I don't know how to do that using obj_description() instead of direct access to pg_description 2) I don't think a performance improvement (if any) in this method is very important Because of the outer join, getColumns() will only work with a backend = 7.1. Since the conditional coding for 7.1/7.2 and jdbc1/jdbc2 is already giving me headaches I didn't pursue a pre-7.1 solution. Regards, Ren? Pijlman [EMAIL PROTECTED] [ Attachment, skipping... ] ---(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 4: Don't 'kill -9' the postmaster
Re: [JDBC] Fix JDBC test suite, set/get transaction isolation level
. -+-+- Regards, Ren? Pijlman ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl [ Attachment, skipping... ] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [JDBC] Patch for doc/jdbc.sgml
Your patch has been added to the PostgreSQL unapplied patches list at: http://candle.pha.pa.us/cgi-bin/pgpatches I will try to apply it within the next 48 hours. Hello, Attached patch is correction for 'doc/jdbc.sgml' of PostgreSQL 7.1.3. Correction content: * I revised a mistake of type (copy and paste). * I revised multiplicity of description. Please review, -- Ryouichi Matsuda [ Attachment, skipping... ] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [JDBC] Troubles using German Umlauts with JDBC
Can I ask, isn't this the meaning if locale? Is the problem that we need locale capability in jdbc? We have a --enable-locale configure option. 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]) -- 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 -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [JDBC] Proposals for jdbc.sgml(in 7.1.3 doc)
Thanks. I am attaching the patch I applied.
Hello,
Followings are proposed fixes to jdbc.sgml(line numbers are for 7.1.3
doc). Comments?
jdbc.sgml
[invalid column's name in a SELECT statement]
lines 579
x PreparedStatement ps = con.prepareStatement(SELECT oid FROM images WHERE
name=?);
o PreparedStatement ps = con.prepareStatement(SELECT imgoid FROM images WHERE
imgname=?);
[the modifier in the document is different from the one in the source]
lines 1280
org.postgresql.geometric.PGcircle
x public double radius
o double radius // in the source, here
[invalid return type]
lines 1996
org.postgresql.largeobject.LargeObject#read()
x public void read(byte buf[],
o public int read(byte buf[],
[the discription of arguments type is incorrectly]
lines 2419
a constructor of org.postgresql.util.Serialize
x public Serialize(Connection c,
String type) throws SQLException
o public Serialize(org.postgresql.Connection c,
String type) throws SQLException
lines 2462, 2504
org.postgresql.util.Seriarize#create()
x public static void create(Connection con,
Object o) throws SQLException
o public static void create(org.postgresql.Connection con,
Object o) throws SQLException
lines 2518
org.postgresql.util.Seriarize#create()
x public static void create(Connection con,
Class o) throws SQLException
o public static void create(org.postgresql.Connection con,
Class o) throws SQLException
[Cannot access to the page]
lines 2910
x See John Dumas's Java Crypt page for the original source.
http://www.zeh.com/local/jfd/crypt.html
(Sorry, I can't find a replacement page.)
Thanks.
Hiroyuki Yatabe([EMAIL PROTECTED])
Software Research Associates, Inc.
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go 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
Index: doc/src/sgml/jdbc.sgml
===
RCS file: /home/projects/pgsql/cvsroot/pgsql/doc/src/sgml/jdbc.sgml,v
retrieving revision 1.22
diff -c -r1.22 jdbc.sgml
*** doc/src/sgml/jdbc.sgml 2001/09/10 21:58:46 1.22
--- doc/src/sgml/jdbc.sgml 2001/09/12 15:46:13
***
*** 576,587
classnameStatement/classname class can equally be used.)
programlisting
! PreparedStatement ps = con.prepareStatement(SELECT oid FROM images WHERE name=?);
ps.setString(1, myimage.gif);
ResultSet rs = ps.executeQuery();
if (rs != null) {
while(rs.next()) {
! InputStream is = rs.getBinaryInputStream(1);
// use the stream in some way here
is.close();
}
--- 576,587
classnameStatement/classname class can equally be used.)
programlisting
! PreparedStatement ps = con.prepareStatement(SELECT imgoid FROM images WHERE
imgname=?);
ps.setString(1, myimage.gif);
ResultSet rs = ps.executeQuery();
if (rs != null) {
while(rs.next()) {
! InputStream is = rs.getBinaryStream(1);
// use the stream in some way here
is.close();
}
***
*** 1277,1283
This is the center point
! public double radius
This is the radius
--- 1277,1283
This is the center point
! double radius
This is the radius
***
*** 1993,1999
listitem
synopsis
! public void read(byte buf[],
int off,
int len) throws SQLException
/synopsis
--- 1993,1999
listitem
synopsis
! public int read(byte buf[],
int off,
int len) throws SQLException
/synopsis
***
*** 2416,2422
Constructors
! public Serialize(Connection c,
String type) throws SQLException
This creates an instance that can be used to serialize
--- 2416,2422
Constructors
! public Serialize(org.postgresql.Connection c,
String type) throws SQLException
This creates an instance that can be used to serialize
***
*** 2459,2465
Throws: SQLException
on error
! public static void create(Connection con,
Object o) throws SQLException
This method is not used by the driver, but it creates a
--- 2459,2465
Throws: SQLException
on error
! public
Re: [JDBC] Using boolean '1' in jdbc2
OK, patch applied.
Bruce,
This patch is fine.
thanks,
--Barry
Bruce Momjian wrote:
I noticed that jdbc1 getBoolean allows '1', while jdbc2 does not. The
following patch makes jdbc2 accept '1' also. Is this OK?
Index: src/interfaces/jdbc/org/postgresql/jdbc2/ResultSet.java
===
RCS file:
/home/projects/pgsql/cvsroot/pgsql/src/interfaces/jdbc/org/postgresql/jdbc2/ResultSet.java,v
retrieving revision 1.33
diff -c -r1.33 ResultSet.java
*** src/interfaces/jdbc/org/postgresql/jdbc2/ResultSet.java 2001/09/10 15:07:05
1.33
--- src/interfaces/jdbc/org/postgresql/jdbc2/ResultSet.java 2001/09/13 16:43:51
***
*** 1396,1402
if (s != null)
{
int c = s.charAt(0);
! return ((c == 't') || (c == 'T'));
}
return false; // SQL NULL
}
--- 1396,1402
if (s != null)
{
int c = s.charAt(0);
! return ((c == 't') || (c == 'T') || (c == '1'));
}
return false; // SQL NULL
}
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
/bjm/diff
Content-Type:
text/plain
Content-Encoding:
7bit
Part 1.3
Content-Type:
text/plain
Content-Encoding:
binary
--
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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [JDBC] Patch for Statement Escape Processing problems
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
Hi all,
I'm attaching a patch which fixes the corruption in strings caused
by escape processing in the SQL statement. I've tested this for a
while now and it appears to work well. Previously string data
with {d was getting corrupt as the {d was being stripped regardless
of whether it was an escape code or not.
I also added checking for time and timestamp escape processing strings
as per 11.3 in the specification. The patch is against the latest
CVS.
Cheers,
Tom.
[ Attachment, skipping... ]
---(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 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [JDBC] UpdateableResultSet patch (not finished yet!)
Sorry, wrong message. This is not in the patch queue. Hello, I have, for some time, now, been working on the updateable resultset class. Please have a look at http://www.miranda.org/~ola/jdbcupr.diff, and let me know what you think. It is only rudimentary at the moment. Things to consider: * Parsing of query. Very hackish at the moment. * Concurrency check. Things that need work: * Documentation * Inserting - nothing done as of yet. * The test case needs to be more elaborate. Ola -- Ola Sundell [EMAIL PROTECTED] - [EMAIL PROTECTED] - [EMAIL PROTECTED] http://miranda.org/~ola ---(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 -- 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] Patch for Statement Escape Processing problems
Patch applied. Thanks.
Hi all,
I'm attaching a patch which fixes the corruption in strings caused
by escape processing in the SQL statement. I've tested this for a
while now and it appears to work well. Previously string data
with {d was getting corrupt as the {d was being stripped regardless
of whether it was an escape code or not.
I also added checking for time and timestamp escape processing strings
as per 11.3 in the specification. The patch is against the latest
CVS.
Cheers,
Tom.
[ Attachment, skipping... ]
---(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 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [JDBC] isNullable()
Patch applied. Thanks. Attached is a patch that fixes ResultSetMetaData.isNullable() in the JDBC driver. This method is currently unimplemented and always returns ResultSetMetaData.columnNullable. This is obviously incorrect when a column is defined with NOT NULL or PRIMARY KEY. And we have to think of check constraints, views, functions etc. The patch simply changes the return value to ResultSetMetaData.columnNullableUnknown. This is until someone comes up with a real implementation of course. On Fri, 14 Sep 2001 17:53:50 +0200, Tomisaw Kity?ski wrote: Hello there, could someone tell me, please, do I have any chance to get proper implementation of above method in JDBC (1.1+) soon? Current return 1 works fine on most tables, however it seems to be a little bit incorrect with some of them ;) Regards, Ren? Pijlman [EMAIL PROTECTED] [ Attachment, skipping... ] ---(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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [JDBC] JDBC test suite patch
Your patch has been added to the PostgreSQL unapplied patches list at: http://candle.pha.pa.us/cgi-bin/pgpatches I will try to apply it within the next 48 hours. I tried sending the email to jdbc and patches on the 17th but it didn't get through. I'm attempting again.. The attached patch is my first run-through of the JDBC test suite. A summary of changes: . removal of the tablename property from build.xml . addition of a dropTable method in JDBC2Tests and cleanups of many methods in the same . all tests now use non-deprecated assertXYZ methods instead of the deprecated assert method . failure in TimestampTest (testSetTimestamp) fixed. The failure is because testSetTimestamp was inserting a timestamp with hour 7 but checkTimeTest was expecting a timestamp with hour 8. AFAICS, there are no issues wrt daylight savings time and timestamps being pushed in and pulled out (but more explicit tests should be added in the future) . failure in TimeTest (testGetTime) fixed. Times to be inserted were interpreted in the localtime zone but checking was done with the assumption that the insertion was done in GMT. . formatting changes in a few of the source files (because I found it convenient to have consistent formatting while working on them). The formatting is consistent with the new format for java source files in PostgreSQL. Liam -- Liam Stewart :: Red Hat Canada, Ltd. :: [EMAIL PROTECTED] [ Attachment, skipping... ] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [JDBC] [PATCHES] Ant configuration
Barry Lind writes: I don't like this patch. If anything I think we should remove the dependency on ANT, not remove the dependency on make. The use of Ant originally seemed attractive because it would solve the detection of the jdk version, the portable invocation of the compiler, and the dependency generation. However, I must currently consider this experiment a failure, because for each problem Ant solves it introduces a load of worse problems into the system. Thus, if we can agree to work out a configure/make-based system for the next release I would be very much for it. I think I can safely at to TODO: JDBC o Move from Ant to Make builds -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: FW: Re: [JDBC] [PATCHES] Ant configuration
I guess I can make an argument either way. The real way to answer this is to ask if one cares if you can build the JDBC driver on window's only platform without cygwin installed. -If the answer is no, that one wouldn't build the JDBC driver without building the rest of postgresql, then the build process should be tied to make, like the rest of postgresql, for simplisity in maintence. -However, if the JDBC driver should be able to be built without having to build postgresql, (on platforms without UNIX-compatiablity layer like cygwin) for client use only, then yes, use Ant to achive platform-independance. One significant issue here is that unlike our other binaries, the JAR files run on any platform so they don't really need to compile in MS Win. They can just download it from a web site or we could ship the jdbc JAR ourselves. -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [JDBC] [PATCHES] DatabaseMetadata patch
Attached is a unified diff to DatabaseMetadata from the jdbc2 interface. It fixes a bug where the metadata does not include the scale/precision of the database columns. We have been using this patch successfully for about 2 years, it would be great to finally get it into the sources. Suggestions/comments welcome. There is no patch attached. Also, have you checkes our current CVS/snapshots to make sure this is still a problem? -- 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://archives.postgresql.org
Re: [JDBC] [PATCHES] DatabaseMetadata patch
Here is a patch for DatabaseMetaData to show precision properly. It is
from Mark Lillywhite. I am adding to the patch queue.
--
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
Index: org/postgresql/jdbc2/DatabaseMetaData.java
===
RCS file: /cvs/pgjdbc71/org/postgresql/jdbc2/DatabaseMetaData.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- org/postgresql/jdbc2/DatabaseMetaData.java 2001/10/04 05:01:32 1.1
+++ org/postgresql/jdbc2/DatabaseMetaData.java 2001/10/23 09:44:30 1.2
@@ -1932,7 +1932,19 @@
tuple[7] = null;// Buffer length
- tuple[8] = 0.getBytes(); // Decimal Digits - how to get this?
+// Decimal digits = scale
+// From the source (see e.g. backend/utils/adt/numeric.c,
+// function numeric()) the scale and precision can be calculated
+// from the typmod value. [EMAIL PROTECTED]
+if (typname.equals(numeric) || typname.equals(decimal))
+{
+ int attypmod = r.getInt(8);
+ tuple[8] =
+Integer.toString((attypmod 0x) - VARHDRSZ).getBytes();
+}
+else
+ tuple[8] = 0.getBytes();
+
tuple[9] = 10.getBytes(); // Num Prec Radix - assume decimal
// tuple[10] is below
---(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] [PATCHES] DatabaseMetadata patch
The patch is missing the corresponding fix for jdbc1/DatabaseMetaData.java. Can you resubmit the patch with a fix for both occurances of the problem? Otherwise the fix looks fine. I have applied the jdbc2 version. It would be nice to have a jdbc1 version too. Thanks. -- 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 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] [PATCHES] DatabaseMetadata patch
Patch applied. Thanks. If you can send a jdbc1 version, that would be
great.
---
Here is a patch for DatabaseMetaData to show precision properly. It is
from Mark Lillywhite. I am adding to the patch queue.
--
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
Index: org/postgresql/jdbc2/DatabaseMetaData.java
===
RCS file: /cvs/pgjdbc71/org/postgresql/jdbc2/DatabaseMetaData.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- org/postgresql/jdbc2/DatabaseMetaData.java2001/10/04 05:01:32 1.1
+++ org/postgresql/jdbc2/DatabaseMetaData.java2001/10/23 09:44:30 1.2
@@ -1932,7 +1932,19 @@
tuple[7] = null;// Buffer length
- tuple[8] = 0.getBytes(); // Decimal Digits - how to get this?
+// Decimal digits = scale
+// From the source (see e.g. backend/utils/adt/numeric.c,
+// function numeric()) the scale and precision can be calculated
+// from the typmod value. [EMAIL PROTECTED]
+if (typname.equals(numeric) || typname.equals(decimal))
+{
+ int attypmod = r.getInt(8);
+ tuple[8] =
+Integer.toString((attypmod 0x) - VARHDRSZ).getBytes();
+}
+else
+ tuple[8] = 0.getBytes();
+
tuple[9] = 10.getBytes(); // Num Prec Radix - assume decimal
// tuple[10] is below
--
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 4: Don't 'kill -9' the postmaster
Re: [JDBC] FW: Re: [PATCHES] Ant configuration
Added to TODO: o Move to using 'make' rather than 'ant'(?) At least we know it is an issue for final decision. --- -- Start of PGP signed section. On 23-Oct-2001 Jayesh K. Parayali wrote: Just a thought. Why not separate postgres and postgres jdbc in that case? To be honest, this is the one thing I want to avoid if possible. Its important that the postgres build system builds the 'official' interfaces as well, since it keeps the two connect tightly. I prefer to use ant to build Java code, but to be honest, I really just want to be able to type either of the following, in the src/interfaces/jdbc directory: ant jar or make jar Both should give the same results. (Its kinda silly that the current technique has 'make' call 'ant', but anyways...) The only two issues are multiple build tools and ease for building the jdbc driver for non-UNIX users. And to be more honest, I think we've spent too much time on this as is. If we can't decide as a group, we should either a) vote on it (Least the CVS committers should) or b) leave it for now. Either way, I'm going to stay out of this discussion for now. Virtually, Ned Wolpert [EMAIL PROTECTED] D08C2F45: 28E7 56CB 58AC C622 5A51 3C42 8B2B 2739 D08C 2F45 -- End of PGP signed section. -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [JDBC] [PATCHES] fix for JDBC test suite
Patch applied. Thanks. A couple of lines were missing from my last patch - this one fixes things. Liam -- Liam Stewart :: Red Hat Canada, Ltd. :: [EMAIL PROTECTED] [ Attachment, skipping... ] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [JDBC] anonymous cvs change ?
Hello, When I retrive pgsql-jdbc source use: cvs -d :pserver:[EMAIL PROTECTED]:/home/projects/pgsql/cvsroot password: postgresql The cvs server report: authorization failed. New location is: :pserver:[EMAIL PROTECTED]:/projects/cvsroot -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [JDBC] [PATCHES] Fix for broken JDBC's getColumn() (take 2)
Your patch has been added to the PostgreSQL unapplied patches list at: http://candle.pha.pa.us/cgi-bin/pgpatches I will try to apply it within the next 48 hours. Hi, Per the recent discussion there's been some code changes in JDBC's DatabaseMetaData.getColumn(). I proposed a patch that would change the number of queries to find out all columns in a table from 2 * N + 1 to 1 (N being the number of columns reported) by using some outer joins. I also fixed the fact that getColumns() only returned columns that had a default defined. OTOH, I did not use to change the code required for obtaining a column's remarks (by using col_description() for 7.2 and requested by Tom Lane). Finally, I have found a way to get all the column details in a single query *and* use col_description() for 7.2 servers. A patch is attached. It overrules Ren? Pijlman's fix for this that was committed just today, but still used N + 1 queries (sorry Ren? ;-) ) I also fixed the return values for TABLE_CAT and TABLE_SCHEM from to null, to be more standard compliant (and requested in Ren?'s mail found at http://fts.postgresql.org/db/mw/msg.html?mid=1034253). As always, the JDBC1 version has not been tested as I have no JDK 1.1 available. Please review, Jeroen [ Attachment, skipping... ] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- 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] [PATCHES] fix for JDBC test suite
Your patch has been added to the PostgreSQL unapplied patches list at: http://candle.pha.pa.us/cgi-bin/pgpatches I will try to apply it within the next 48 hours. A couple of lines were missing from my last patch - this one fixes things. Liam -- Liam Stewart :: Red Hat Canada, Ltd. :: [EMAIL PROTECTED] [ Attachment, skipping... ] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- 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 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] [PATCHES] Fix for broken JDBC's getColumn() (take 2)
Patch applied. Thanks. Hi, Per the recent discussion there's been some code changes in JDBC's DatabaseMetaData.getColumn(). I proposed a patch that would change the number of queries to find out all columns in a table from 2 * N + 1 to 1 (N being the number of columns reported) by using some outer joins. I also fixed the fact that getColumns() only returned columns that had a default defined. OTOH, I did not use to change the code required for obtaining a column's remarks (by using col_description() for 7.2 and requested by Tom Lane). Finally, I have found a way to get all the column details in a single query *and* use col_description() for 7.2 servers. A patch is attached. It overrules Ren? Pijlman's fix for this that was committed just today, but still used N + 1 queries (sorry Ren? ;-) ) I also fixed the return values for TABLE_CAT and TABLE_SCHEM from to null, to be more standard compliant (and requested in Ren?'s mail found at http://fts.postgresql.org/db/mw/msg.html?mid=1034253). As always, the JDBC1 version has not been tested as I have no JDK 1.1 available. Please review, Jeroen [ Attachment, skipping... ] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- 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://archives.postgresql.org
