Patch for broken JDBC&#39;s getColumn()

http://candle.pha.pa.us/cgi-bin/pgpatches

bruce@momjian.us

almost 25 years ago

In reply to: Jeroen van Vianen (#1)

Re: [PATCHES] Patch for broken JDBC's getColumn()

Your patch has been added to the PostgreSQL unapplied patches list at:

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

pg@fastcrypt.com

almost 25 years ago

In reply to: Bruce Momjian (#2)

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);
}
}
}

pg@fastcrypt.com

almost 25 years ago

In reply to: Dave Cramer (#3)

Re: Read transactions don't work on 7.0.x db's

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 static void main(String[] args)
{

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

barry@xythos.com

almost 25 years ago

In reply to: Dave Cramer (#4)

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:

Show quoted text

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

pg@fastcrypt.com

almost 25 years ago

In reply to: Dave Cramer (#4)

Re: Read transactions don't work on 7.0.x db's Disregard my other patch

The first one considered everything changed ?

I also fixed the rollback method in this one, assuming it was broken the
same way

Dave

pg@fastcrypt.com

almost 25 years ago

In reply to: Barry Lind (#5)

Re: Read transactions don't work on 7.0.x db's

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?

thanks,
--Barry

Dave Cramer wrote:

Show quoted text

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@xythos.com

almost 25 years ago

In reply to: Dave Cramer (#4)

Re: Read transactions don't work on 7.0.x db's

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:

Show quoted text

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

Tom Lane

tgl@sss.pgh.pa.us

almost 25 years ago

In reply to: Barry Lind (#8)

Re: Read transactions don't work on 7.0.x db's

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

#10

pg@fastcrypt.com

almost 25 years ago

In reply to: Tom Lane (#9)

Re: Read transactions don't work on 7.0.x db's

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

Show quoted text

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

#11

barry@xythos.com

almost 25 years ago

In reply to: Dave Cramer (#4)

Re: Read transactions don't work on 7.0.x db's

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:

Show quoted text

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

#12

http://candle.pha.pa.us/cgi-bin/pgpatches

bruce@momjian.us

almost 25 years ago

In reply to: Dave Cramer (#6)

Re: 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:

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

#13

bruce@momjian.us

almost 25 years ago

In reply to: Dave Cramer (#6)

Re: 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 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

#14

pg@fastcrypt.com

almost 25 years ago

In reply to: Barry Lind (#11)

Re: Read transactions don't work on 7.0.x db's 2nd patch

Here is a revised patch with Barry's suggestions implemented

Dave

#15

barry@xythos.com

almost 25 years ago

In reply to: Dave Cramer (#4)

Re: Read transactions don't work on 7.0.x db's 2nd patch

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:

Show quoted text

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

#16

pg@fastcrypt.com

almost 25 years ago

In reply to: Dave Cramer (#14)

Re: Read transactions don't work on 7.0.x db's 3rd attempt

-----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

#17

bruce@momjian.us

almost 25 years ago

In reply to: Jeroen van Vianen (#1)

Re: [PATCHES] Patch for broken JDBC's getColumn()

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

#18

bruce@momjian.us

almost 25 years ago

In reply to: Bruce Momjian (#17)

Re: Patch for broken JDBC's getColumn()

Patch applied and attached. Seems the line was in jdbc1 and jdbc2.
Thanks.

-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
Sent: Thursday, September 06, 2001 05:20
To: Jeroen van Vianen
Cc: pgsql-patches@postgresql.org; pgsql-jdbc@postgresql.org
Subject: Re: [PATCHES] Patch for broken JDBC's getColumn()

Patch applied. Thanks.

Thanks. However, I seem to have left a single debug statement in there :-(

Here's a patch to remove it.

Thanks,

Jeroen

[ Attachment, skipping... ]

-- 
  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

Import Notes

Reply to msg id not found: F9926D32A30ED511B8E30050044AB52E101479@ams010.satama.nl | Resolved by subject fallback

#19

barry@xythos.com

almost 25 years ago

In reply to: Dave Cramer (#16)

Re: Read transactions don't work on 7.0.x db's 3rd attempt

Looks good.

--Barry

Dave Cramer wrote:

Show quoted text

-----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

#20

http://candle.pha.pa.us/cgi-bin/pgpatches

bruce@momjian.us

almost 25 years ago

In reply to: Dave Cramer (#16)

Re: 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:

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

#21