Thread: Patch for broken JDBC's getColumn()
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
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 majordomo@postgresql.org
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
The following code fails on a 7.0 db, but works on a 7.1 db
It works fine with the 7.0 jar, but not with the latest code
I had a quick look and everything looks ok. I am going to keep looking
but I thought I would throw this out and see if anyone knows what is
going on
Dave
package test;
import java.sql.*;
/**
* Title:
* Description:
* Copyright: Copyright (c) 2001
* Company:
* @author
* @version 1.0
*/
public class TransactionSelect {
public TransactionSelect()
{
}
public static Connection getConnection( String url, String user,
String password)
{
try {
Class.forName("org.postgresql.Driver");
return java.sql.DriverManager.getConnection(url,user,password);
} catch(ClassNotFoundException ex) {
ex.printStackTrace(System.out);
} catch(SQLException ex) {
ex.printStackTrace(System.out);
}
return null;
}
public static void main(String[] args)
{
try{
Connection con =
getConnection("jdbc:postgresql://192.168.1.1/davec","davec","");
if (con == null){
throw new RuntimeException("no Connection");
}
con.setAutoCommit(false);
PreparedStatement pstmt = con.prepareStatement("select * from
categories" );
ResultSet rs = pstmt.executeQuery();
con.commit();
con.close();
}catch (SQLException ex){
ex.printStackTrace(System.out);
}
}
}
Here's a patch to fix the problem below
Dave
-----Original Message-----
From: pgsql-jdbc-owner@postgresql.org
[mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Dave Cramer
Sent: August 30, 2001 8:51 PM
To: pgsql-jdbc@postgresql.org
Subject: [JDBC] Read transactions don't work on 7.0.x db's
The following code fails on a 7.0 db, but works on a 7.1 db
It works fine with the 7.0 jar, but not with the latest code
I had a quick look and everything looks ok. I am going to keep looking
but I thought I would throw this out and see if anyone knows what is
going on
Dave
package test;
import java.sql.*;
/**
* Title:
* Description:
* Copyright: Copyright (c) 2001
* Company:
* @author
* @version 1.0
*/
public class TransactionSelect {
public TransactionSelect()
{
}
public static Connection getConnection( String url, String user,
String password)
{
try {
Class.forName("org.postgresql.Driver");
return java.sql.DriverManager.getConnection(url,user,password);
} catch(ClassNotFoundException ex) {
ex.printStackTrace(System.out);
} catch(SQLException ex) {
ex.printStackTrace(System.out);
}
return null;
}
public static void main(String[] args)
{
try{
Connection con =
getConnection("jdbc:postgresql://192.168.1.1/davec","davec","");
if (con == null){
throw new RuntimeException("no Connection");
}
con.setAutoCommit(false);
PreparedStatement pstmt = con.prepareStatement("select * from
categories" );
ResultSet rs = pstmt.executeQuery();
con.commit();
con.close();
}catch (SQLException ex){
ex.printStackTrace(System.out);
}
}
}
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
Attachment
Dave,
You never really explained what the problem was. What error were you
getting, and what does this fix solve?
Also, the patch you have sent reports the entire file as being changed.
That is not useful to review. Can you send a followup to the list
with a better explaination and a patch that can be more easily be reviewed.
thanks,
--Barry
Dave Cramer wrote:
> Here's a patch to fix the problem below
>
> Dave
>
> -----Original Message-----
> From: pgsql-jdbc-owner@postgresql.org
> [mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Dave Cramer
> Sent: August 30, 2001 8:51 PM
> To: pgsql-jdbc@postgresql.org
> Subject: [JDBC] Read transactions don't work on 7.0.x db's
>
>
> The following code fails on a 7.0 db, but works on a 7.1 db
>
> It works fine with the 7.0 jar, but not with the latest code
>
> I had a quick look and everything looks ok. I am going to keep looking
> but I thought I would throw this out and see if anyone knows what is
> going on
>
> Dave
>
> package test;
> import java.sql.*;
> /**
> * Title:
> * Description:
> * Copyright: Copyright (c) 2001
> * Company:
> * @author
> * @version 1.0
> */
>
> public class TransactionSelect {
>
> public TransactionSelect()
> {
> }
> public static Connection getConnection( String url, String user,
> String password)
> {
> try {
> Class.forName("org.postgresql.Driver");
> return java.sql.DriverManager.getConnection(url,user,password);
> } catch(ClassNotFoundException ex) {
> ex.printStackTrace(System.out);
> } catch(SQLException ex) {
> ex.printStackTrace(System.out);
> }
> return null;
> }
>
> public static void main(String[] args)
> {
>
> try{
> Connection con =
> getConnection("jdbc:postgresql://192.168.1.1/davec","davec","");
> if (con == null){
> throw new RuntimeException("no Connection");
> }
> con.setAutoCommit(false);
> PreparedStatement pstmt = con.prepareStatement("select * from
> categories" );
> ResultSet rs = pstmt.executeQuery();
> con.commit();
> con.close();
> }catch (SQLException ex){
> ex.printStackTrace(System.out);
> }
> }
> }
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>
>
>
> ------------------------------------------------------------------------
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://www.postgresql.org/search.mpl
>
> Connection.patch
>
> Content-Type:
>
> application/octet-stream
> Content-Encoding:
>
> quoted-printable
>
>
> ------------------------------------------------------------------------
> Part 1.3
>
> Content-Type:
>
> text/plain
> Content-Encoding:
>
> binary
>
>
The first one considered everything changed ? I also fixed the rollback method in this one, assuming it was broken the same way Dave
Attachment
Barry,
I already resent the patch. I realized the error of my patch a few
minutes ago.
The problem is: apparently you can't executeSQL("commit; begin",
getIsolationLevel()); all in one go
I had to break it into separate execSQL calls
Dave
-----Original Message-----
From: Barry Lind [mailto:barry@xythos.com]
Sent: August 31, 2001 1:15 PM
To: Dave@micro-automation.net
Cc: pgsql-jdbc@postgresql.org
Subject: Re: Read transactions don't work on 7.0.x db's
Dave,
You never really explained what the problem was. What error were you
getting, and what does this fix solve?
Also, the patch you have sent reports the entire file as being changed.
That is not useful to review. Can you send a followup to the list
with a better explaination and a patch that can be more easily be
reviewed.
thanks,
--Barry
Dave Cramer wrote:
> Here's a patch to fix the problem below
>
> Dave
>
> -----Original Message-----
> From: pgsql-jdbc-owner@postgresql.org
> [mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Dave Cramer
> Sent: August 30, 2001 8:51 PM
> To: pgsql-jdbc@postgresql.org
> Subject: [JDBC] Read transactions don't work on 7.0.x db's
>
>
> The following code fails on a 7.0 db, but works on a 7.1 db
>
> It works fine with the 7.0 jar, but not with the latest code
>
> I had a quick look and everything looks ok. I am going to keep looking
> but I thought I would throw this out and see if anyone knows what is
> going on
>
> Dave
>
> package test;
> import java.sql.*;
> /**
> * Title:
> * Description:
> * Copyright: Copyright (c) 2001
> * Company:
> * @author
> * @version 1.0
> */
>
> public class TransactionSelect {
>
> public TransactionSelect()
> {
> }
> public static Connection getConnection( String url, String user,
> String password)
> {
> try {
> Class.forName("org.postgresql.Driver");
> return java.sql.DriverManager.getConnection(url,user,password);
> } catch(ClassNotFoundException ex) {
> ex.printStackTrace(System.out);
> } catch(SQLException ex) {
> ex.printStackTrace(System.out);
> }
> return null;
> }
>
> public static void main(String[] args)
> {
>
> try{
> Connection con =
> getConnection("jdbc:postgresql://192.168.1.1/davec","davec","");
> if (con == null){
> throw new RuntimeException("no Connection");
> }
> con.setAutoCommit(false);
> PreparedStatement pstmt = con.prepareStatement("select * from
> categories" );
> ResultSet rs = pstmt.executeQuery();
> con.commit();
> con.close();
> }catch (SQLException ex){
> ex.printStackTrace(System.out);
> }
> }
> }
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>
>
>
> ----------------------------------------------------------------------
> --
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://www.postgresql.org/search.mpl
>
> Connection.patch
>
> Content-Type:
>
> application/octet-stream
> Content-Encoding:
>
> quoted-printable
>
>
> ----------------------------------------------------------------------
> --
> Part 1.3
>
> Content-Type:
>
> text/plain
> Content-Encoding:
>
> binary
>
>
Dave,
The multiple statements in one call is there for performance reasons.
Please don't remove it entirely since it works fine in 7.1 and 7.2.
Instead your fix should be conditional based on server version:
if (autoCommit)
ExecSQL("end");
else {
ifMinumumServerVersion("7.1") {
ExecSQL("begin; " + getIsolationLevelSQL());
} else {
ExecSQL("begin");
ExecSQL(getIsolationLevelSQL());
}
}
thanks,
--Barry
Dave Cramer wrote:
> Here's a patch to fix the problem below
>
> Dave
>
> -----Original Message-----
> From: pgsql-jdbc-owner@postgresql.org
> [mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Dave Cramer
> Sent: August 30, 2001 8:51 PM
> To: pgsql-jdbc@postgresql.org
> Subject: [JDBC] Read transactions don't work on 7.0.x db's
>
>
> The following code fails on a 7.0 db, but works on a 7.1 db
>
> It works fine with the 7.0 jar, but not with the latest code
>
> I had a quick look and everything looks ok. I am going to keep looking
> but I thought I would throw this out and see if anyone knows what is
> going on
>
> Dave
>
> package test;
> import java.sql.*;
> /**
> * Title:
> * Description:
> * Copyright: Copyright (c) 2001
> * Company:
> * @author
> * @version 1.0
> */
>
> public class TransactionSelect {
>
> public TransactionSelect()
> {
> }
> public static Connection getConnection( String url, String user,
> String password)
> {
> try {
> Class.forName("org.postgresql.Driver");
> return java.sql.DriverManager.getConnection(url,user,password);
> } catch(ClassNotFoundException ex) {
> ex.printStackTrace(System.out);
> } catch(SQLException ex) {
> ex.printStackTrace(System.out);
> }
> return null;
> }
>
> public static void main(String[] args)
> {
>
> try{
> Connection con =
> getConnection("jdbc:postgresql://192.168.1.1/davec","davec","");
> if (con == null){
> throw new RuntimeException("no Connection");
> }
> con.setAutoCommit(false);
> PreparedStatement pstmt = con.prepareStatement("select * from
> categories" );
> ResultSet rs = pstmt.executeQuery();
> con.commit();
> con.close();
> }catch (SQLException ex){
> ex.printStackTrace(System.out);
> }
> }
> }
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>
>
>
> ------------------------------------------------------------------------
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://www.postgresql.org/search.mpl
>
> Connection.patch
>
> Content-Type:
>
> application/octet-stream
> Content-Encoding:
>
> quoted-printable
>
>
> ------------------------------------------------------------------------
> Part 1.3
>
> Content-Type:
>
> text/plain
> Content-Encoding:
>
> binary
>
>
Barry Lind <barry@xythos.com> writes:
> The multiple statements in one call is there for performance reasons.
> Please don't remove it entirely since it works fine in 7.1 and 7.2.
> Instead your fix should be conditional based on server version:
Given that someone else is proposing a patch that will break backward
compatibility to 7.0 servers anyway, I'm unconvinced that we need this
at all. Perhaps a discussion about the costs and benefits of backwards
compatibility in the JDBC driver is needed --- what tradeoffs do people
want to make?
regards, tom lane
From my POV there are two "costs" here: 1) The speed degradation by supporting multiple versions of postgres. I tend not to be too concerned by speed, and more concerned with ease of use. If speed really becomes an issue I can go into the code and remove the offending inefficiency caused by supporting multiple versions. 2) The barrier to entry by new jdbc, and postgres users trying to use postgres, and jdbc for the first time. If it doesn't work out of the box, then they will leave. I have a bias towards making it easier for people to use the software. However given the speed of server development. How far "back" are we going to support ? An argument can be made that since the software is free then there really is no reason not to upgrade. The biggest reason for me not to upgrade my server is reliability. What I have now works! I am hesitant to upgrade the server on a server which needs to run 24/7. That being said I am more likely to upgrade the jdbc driver, since: 1) it is really easy to back out the upgrade. 2) I have some ability to debug the jdbc driver and figure out what is going wrong. My ability to debug the postgres server is significantly less (approaching 0). So along with making it easier for new people to get the code up and running with a minimum of effort. I would like to take advantage of new jdbc features on older servers. My 2 cents worth Dave On Mon, 2001-09-03 at 19:46, Tom Lane wrote: > Barry Lind <barry@xythos.com> writes: > > The multiple statements in one call is there for performance reasons. > > Please don't remove it entirely since it works fine in 7.1 and 7.2. > > Instead your fix should be conditional based on server version: > > Given that someone else is proposing a patch that will break backward > compatibility to 7.0 servers anyway, I'm unconvinced that we need this > at all. Perhaps a discussion about the costs and benefits of backwards > compatibility in the JDBC driver is needed --- what tradeoffs do people > want to make? > > regards, tom lane > >
I think it is important to support backward compatibility in code like the JDBC driver. It is often the case that code opperates in an environment where there may be servers at different release levels (production databases on 7.0, while dev databases are on 7.1). Thus I think that maintaining backward compatibility to the previous release is a minimum requirement. Begining with the 7.2 JDBC code it is now possible to support backward compatibility (i.e. methods now exist to conditionally execute code based on server version). That wasn't the case before now. In fact the 7.1 JDBC code is not backward compatible with 7.0 (although the incompatibilies are in areas that many users may not notice and thus for many it is backwardly compatible). I am not sure how far back to maintain backward compatibility. I think it is dependent on how often new server versions are released. In general I would not want to force a database user to upgrade more than once per year (since doing a dump/restore on a large database can be a large hastle). Therefore I would recommend that going forward the JDBC drivers support all back releases that where the latest release within the last year. For example since 7.1 came out in April 2001, this would mean supporting 7.0 until April 2002. And if 7.2 when production in October 2001, then 7.1 should be supported until October 2002. thanks, --Barry Tom Lane wrote: > Barry Lind <barry@xythos.com> writes: > >>The multiple statements in one call is there for performance reasons. >>Please don't remove it entirely since it works fine in 7.1 and 7.2. >>Instead your fix should be conditional based on server version: >> > > Given that someone else is proposing a patch that will break backward > compatibility to 7.0 servers anyway, I'm unconvinced that we need this > at all. Perhaps a discussion about the costs and benefits of backwards > compatibility in the JDBC driver is needed --- what tradeoffs do people > want to make? > > regards, tom lane > >
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 majordomo@postgresql.org
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
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 majordomo@postgresql.org -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Here is a revised patch with Barry's suggestions implemented Dave
Attachment
Dave,
There is a bug in this patch. In the rollback case, you have:
> ! ExecSQL("rollback; begin"+getIsolationLevelSQL());
You are missing a semicolon after the begin.
thanks,
--Barry
Dave Cramer wrote:
> Here is a revised patch with Barry's suggestions implemented
>
> Dave
>
>
> ------------------------------------------------------------------------
>
> Index: Connection.java
> ===================================================================
> RCS file: /home/projects/pgsql/cvsroot/pgsql/src/interfaces/jdbc/org/postgresql/Connection.java,v
> retrieving revision 1.26
> diff -c -r1.26 Connection.java
> *** Connection.java 2001/08/24 16:50:12 1.26
> --- Connection.java 2001/09/04 17:21:29
> ***************
> *** 906,912 ****
> if (autoCommit)
> ExecSQL("end");
> else {
> ! ExecSQL("begin; " + getIsolationLevelSQL());
> }
> this.autoCommit = autoCommit;
> }
> --- 906,917 ----
> if (autoCommit)
> ExecSQL("end");
> else {
> ! if (haveMinimumServerVersion("7.1")){
> ! ExecSQL("begin;"+getIsolationLevelSQL());
> ! }else{
> ! ExecSQL("begin");
> ! ExecSQL(getIsolationLevelSQL());
> ! }
> }
> this.autoCommit = autoCommit;
> }
> ***************
> *** 935,941 ****
> public void commit() throws SQLException {
> if (autoCommit)
> return;
> ! ExecSQL("commit; begin; " + getIsolationLevelSQL());
> }
>
> /**
> --- 940,952 ----
> public void commit() throws SQLException {
> if (autoCommit)
> return;
> ! if (haveMinimumServerVersion("7.1")){
> ! ExecSQL("commit;begin;"+getIsolationLevelSQL());
> ! }else{
> ! ExecSQL("commit");
> ! ExecSQL("begin");
> ! ExecSQL(getIsolationLevelSQL());
> ! }
> }
>
> /**
> ***************
> *** 949,955 ****
> public void rollback() throws SQLException {
> if (autoCommit)
> return;
> ! ExecSQL("rollback; begin; " + getIsolationLevelSQL());
> }
>
> /**
> --- 960,972 ----
> public void rollback() throws SQLException {
> if (autoCommit)
> return;
> ! if (haveMinimumServerVersion("7.1")){
> ! ExecSQL("rollback; begin"+getIsolationLevelSQL());
> ! }else{
> ! ExecSQL("rollback");
> ! ExecSQL("begin");
> ! ExecSQL(getIsolationLevelSQL());
> ! }
> }
>
> /**
> ***************
> *** 1035,1055 ****
> if (haveMinimumServerVersion("7.1")) {
> return "";
> }
> ! String q = "SET TRANSACTION ISOLATION LEVEL";
>
> switch(isolationLevel) {
> case java.sql.Connection.TRANSACTION_READ_COMMITTED:
> ! q = q + " READ COMMITTED";
> break;
>
> case java.sql.Connection.TRANSACTION_SERIALIZABLE:
> ! q = q + " SERIALIZABLE";
> break;
>
> default:
> throw new PSQLException("postgresql.con.isolevel",new Integer(isolationLevel));
> }
> ! return q;
> }
>
> /**
> --- 1052,1072 ----
> if (haveMinimumServerVersion("7.1")) {
> return "";
> }
> ! StringBuffer sb = new StringBuffer("SET TRANSACTION ISOLATION LEVEL");
>
> switch(isolationLevel) {
> case java.sql.Connection.TRANSACTION_READ_COMMITTED:
> ! sb.append(" READ COMMITTED");
> break;
>
> case java.sql.Connection.TRANSACTION_SERIALIZABLE:
> ! sb.append(" SERIALIZABLE");
> break;
>
> default:
> throw new PSQLException("postgresql.con.isolevel",new Integer(isolationLevel));
> }
> ! return sb.toString();
> }
>
> /**
>
>
> ------------------------------------------------------------------------
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://www.postgresql.org/search.mpl
>
> Connection.patch
>
> Content-Type:
>
> text/plain
> Content-Encoding:
>
> 7bit
>
>
> ------------------------------------------------------------------------
> Part 1.3
>
> Content-Type:
>
> text/plain
> Content-Encoding:
>
> binary
>
>
-----Original Message----- From: pgsql-jdbc-owner@postgresql.org [mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Dave Cramer Sent: September 4, 2001 1:21 PM To: pgsql-jdbc@postgresql.org 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
Patch applied. Thanks. > 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 majordomo@postgresql.org -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Looks good. --Barry Dave Cramer wrote: > > -----Original Message----- > From: pgsql-jdbc-owner@postgresql.org > [mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Dave Cramer > Sent: September 4, 2001 1:21 PM > To: pgsql-jdbc@postgresql.org > 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 > > > ------------------------------------------------------------------------ > > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://www.postgresql.org/search.mpl > > Connection.patch > > Content-Type: > > application/octet-stream > Content-Encoding: > > quoted-printable > > > ------------------------------------------------------------------------ > Part 1.3 > > Content-Type: > > text/plain > Content-Encoding: > > binary > >
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: pgsql-jdbc-owner@postgresql.org
> [mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Dave Cramer
> Sent: September 4, 2001 1:21 PM
> To: pgsql-jdbc@postgresql.org
> 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
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Patch applied. Thanks. > > > -----Original Message----- > From: pgsql-jdbc-owner@postgresql.org > [mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Dave Cramer > Sent: September 4, 2001 1:21 PM > To: pgsql-jdbc@postgresql.org > 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 pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026