Thread: Couple of patches for jdbc driver
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Folks-
Got two patches that were found by folks on the Castor list, that we'd like to
submit. These were done for the jdbc2 driver. The first one is for support
of the Types.BIT in the PreparedStatement class. The following lines need to be
inserted in the switch statment, at around line 530:
(Prepared statment, line 554, before the default: switch
case Types.BIT:
if (x instanceof Boolean) {
set(parameterIndex, ((Boolean)x).booleanValue() ? "TRUE" : "FALSE");
} else {
throw new PSQLException("postgresql.prep.type");
}
break;
The second one is dealing with blobs,
inserted in PreparedStatemant.java (After previous patch line, 558):
case Types.BINARY:
case Types.VARBINARY:
setObject(parameterIndex,x);
break;
and in ResultSet.java (Around line 857):
case Types.BINARY:
case Types.VARBINARY:
return getBytes(columnIndex);
Virtually,
Ned Wolpert <ned.wolpert@knowledgenet.com>
D08C2F45: 28E7 56CB 58AC C622 5A51 3C42 8B2B 2739 D08C 2F45
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.5 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE7H6r8iysnOdCML0URAtk1AJ9iG99AMLmQblpr6vK2wbhtek6JMwCeJlzP
WGJ5f75GS56BEqWy9a+UpcA=
=ZcOR
-----END PGP SIGNATURE-----
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.
> Folks-
>
> Got two patches that were found by folks on the Castor list, that we'd like to
> submit. These were done for the jdbc2 driver. The first one is for support
> of the Types.BIT in the PreparedStatement class. The following lines need to be
> inserted in the switch statment, at around line 530:
>
>
> (Prepared statment, line 554, before the default: switch
> case Types.BIT:
> if (x instanceof Boolean) {
> set(parameterIndex, ((Boolean)x).booleanValue() ? "TRUE" : "FALSE");
> } else {
> throw new PSQLException("postgresql.prep.type");
> }
> break;
>
>
> The second one is dealing with blobs,
>
> inserted in PreparedStatemant.java (After previous patch line, 558):
> case Types.BINARY:
> case Types.VARBINARY:
> setObject(parameterIndex,x);
> break;
> and in ResultSet.java (Around line 857):
> case Types.BINARY:
> case Types.VARBINARY:
> return getBytes(columnIndex);
>
>
>
> Virtually,
> Ned Wolpert <ned.wolpert@knowledgenet.com>
>
> D08C2F45: 28E7 56CB 58AC C622 5A51 3C42 8B2B 2739 D08C 2F45
-- End of PGP signed section.
--
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 attached and applied.
-- Start of PGP signed section.
> Folks-
>
> Got two patches that were found by folks on the Castor list, that we'd like to
> submit. These were done for the jdbc2 driver. The first one is for support
> of the Types.BIT in the PreparedStatement class. The following lines need to be
> inserted in the switch statment, at around line 530:
>
>
> (Prepared statment, line 554, before the default: switch
> case Types.BIT:
> if (x instanceof Boolean) {
> set(parameterIndex, ((Boolean)x).booleanValue() ? "TRUE" : "FALSE");
> } else {
> throw new PSQLException("postgresql.prep.type");
> }
> break;
>
>
> The second one is dealing with blobs,
>
> inserted in PreparedStatemant.java (After previous patch line, 558):
> case Types.BINARY:
> case Types.VARBINARY:
> setObject(parameterIndex,x);
> break;
> and in ResultSet.java (Around line 857):
> case Types.BINARY:
> case Types.VARBINARY:
> return getBytes(columnIndex);
>
>
>
> Virtually,
> Ned Wolpert <ned.wolpert@knowledgenet.com>
>
> D08C2F45: 28E7 56CB 58AC C622 5A51 3C42 8B2B 2739 D08C 2F45
-- End of PGP signed section.
--
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
Index: src/interfaces/jdbc/org/postgresql/jdbc1/PreparedStatement.java
===================================================================
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/interfaces/jdbc/org/postgresql/jdbc1/PreparedStatement.java,v
retrieving revision 1.6
diff -c -r1.6 PreparedStatement.java
*** src/interfaces/jdbc/org/postgresql/jdbc1/PreparedStatement.java 2001/05/16 17:22:25 1.6
--- src/interfaces/jdbc/org/postgresql/jdbc1/PreparedStatement.java 2001/06/11 21:53:37
***************
*** 489,494 ****
--- 489,505 ----
case Types.TIMESTAMP:
setTimestamp(parameterIndex, (Timestamp)x);
break;
+ case Types.BIT:
+ if (x instanceof Boolean) {
+ set(parameterIndex, ((Boolean)x).booleanValue() ? "TRUE" : "FALSE");
+ } else {
+ throw new PSQLException("postgresql.prep.type");
+ }
+ break;
+ case Types.BINARY:
+ case Types.VARBINARY:
+ setObject(parameterIndex,x);
+ break;
case Types.OTHER:
setString(parameterIndex, ((PGobject)x).getValue());
break;
Index: src/interfaces/jdbc/org/postgresql/jdbc1/ResultSet.java
===================================================================
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/interfaces/jdbc/org/postgresql/jdbc1/ResultSet.java,v
retrieving revision 1.14
diff -c -r1.14 ResultSet.java
*** src/interfaces/jdbc/org/postgresql/jdbc1/ResultSet.java 2001/05/28 00:36:59 1.14
--- src/interfaces/jdbc/org/postgresql/jdbc1/ResultSet.java 2001/06/11 21:53:37
***************
*** 806,811 ****
--- 806,814 ----
return getTime(columnIndex);
case Types.TIMESTAMP:
return getTimestamp(columnIndex);
+ case Types.BINARY:
+ case Types.VARBINARY:
+ return getBytes(columnIndex);
default:
return connection.getObject(field.getTypeName(), getString(columnIndex));
}
Index: src/interfaces/jdbc/org/postgresql/jdbc2/PreparedStatement.java
===================================================================
RCS file: /home/projects/pgsql/cvsroot/pgsql/src/interfaces/jdbc/org/postgresql/jdbc2/PreparedStatement.java,v
retrieving revision 1.10
diff -c -r1.10 PreparedStatement.java
*** src/interfaces/jdbc/org/postgresql/jdbc2/PreparedStatement.java 2001/05/16 17:22:25 1.10
--- src/interfaces/jdbc/org/postgresql/jdbc2/PreparedStatement.java 2001/06/11 21:53:38
***************
*** 549,554 ****
--- 549,565 ----
case Types.TIMESTAMP:
setTimestamp(parameterIndex, (Timestamp)x);
break;
+ case Types.BIT:
+ if (x instanceof Boolean) {
+ set(parameterIndex, ((Boolean)x).booleanValue() ? "TRUE" : "FALSE");
+ } else {
+ throw new PSQLException("postgresql.prep.type");
+ }
+ break;
+ case Types.BINARY:
+ case Types.VARBINARY:
+ setObject(parameterIndex,x);
+ break;
case Types.OTHER:
setString(parameterIndex, ((PGobject)x).getValue());
break;
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.26
diff -c -r1.26 ResultSet.java
*** src/interfaces/jdbc/org/postgresql/jdbc2/ResultSet.java 2001/05/30 16:34:49 1.26
--- src/interfaces/jdbc/org/postgresql/jdbc2/ResultSet.java 2001/06/11 21:53:39
***************
*** 855,860 ****
--- 855,863 ----
return getTime(columnIndex);
case Types.TIMESTAMP:
return getTimestamp(columnIndex);
+ case Types.BINARY:
+ case Types.VARBINARY:
+ return getBytes(columnIndex);
default:
return connection.getObject(field.getTypeName(), getString(columnIndex));
}
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Bruce-
I checked the 7.1.3 release, and this patch isn't there... but it is in CVS.
(You patched this about two months ago.) Specifically, the 1.11 version of
jdbc2/PreparedStatment.java file has the patch, but the 7.1.3 released does
not. How do we propragate patches into the main branch for releasing?
On 11-Jun-2001 Bruce Momjian wrote:
>
> Patch attached and applied.
>
> -- Start of PGP signed section.
>> Folks-
>>
>> Got two patches that were found by folks on the Castor list, that we'd
>> like to
>> submit. These were done for the jdbc2 driver. The first one is for support
>> of the Types.BIT in the PreparedStatement class. The following lines need
>> to be
>> inserted in the switch statment, at around line 530:
>>
>>
>> (Prepared statment, line 554, before the default: switch
>> case Types.BIT:
>> if (x instanceof Boolean) {
>> set(parameterIndex, ((Boolean)x).booleanValue() ? "TRUE" :
>> "FALSE");
>> } else {
>> throw new PSQLException("postgresql.prep.type");
>> }
>> break;
>>
>>
>> The second one is dealing with blobs,
>>
>> inserted in PreparedStatemant.java (After previous patch line, 558):
>> case Types.BINARY:
>> case Types.VARBINARY:
>> setObject(parameterIndex,x);
>> break;
>> and in ResultSet.java (Around line 857):
>> case Types.BINARY:
>> case Types.VARBINARY:
>> return getBytes(columnIndex);
>>
>>
>>
>> Virtually,
>> Ned Wolpert <ned.wolpert@knowledgenet.com>
>>
>> D08C2F45: 28E7 56CB 58AC C622 5A51 3C42 8B2B 2739 D08C 2F45
> -- End of PGP signed section.
>
> --
> 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
>
Virtually,
Ned Wolpert <ned.wolpert@knowledgenet.com>
D08C2F45: 28E7 56CB 58AC C622 5A51 3C42 8B2B 2739 D08C 2F45
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE7gqPeiysnOdCML0URAp11AJ9SAouQhtGNDo0q3agQp6oD5ML50gCdHe0M
NQvY1adpeWIbZ9ONzDkEAH4=
=s6U1
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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? On 21-Aug-2001 Tom Lane wrote: > Ned Wolpert <ned.wolpert@knowledgenet.com> writes: >> (You patched this about two months ago.) Specifically, the 1.11 version of >> jdbc2/PreparedStatment.java file has the patch, but the 7.1.3 released does >> not. How do we propragate patches into the main branch for releasing? > > At this point, we don't; it's quite unlikely that there will be a 7.1.4, > considering that we hope to be in 7.2 beta within a month. > > As far as JDBC goes, lots of people seem to be using CVS snapshots quite > happily, so I'm not sure an official back-patch is needed anyway. > > regards, tom lane Virtually, Ned Wolpert <ned.wolpert@knowledgenet.com> D08C2F45: 28E7 56CB 58AC C622 5A51 3C42 8B2B 2739 D08C 2F45 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7grT5iysnOdCML0URAjg3AJ9Zb45j8askvzCw4KeJes4Tx6zDSQCffcE7 HgvGPQt1/OnREkzSfG4AS90= =vUv3 -----END PGP SIGNATURE-----
Ned Wolpert <ned.wolpert@knowledgenet.com> writes:
> 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
No, they went into current development sources, 7.2-to-be. At this
point 7.1.* is a maintenance branch, and is only changed for low-risk,
high-importance bug fixes. Nobody made the case for any JDBC fixes
to be treated as such, so they didn't get patched into 7.1.*.
> Is there a way for my patches to make it into the next release, which I
> assume is 7.2?
Should be in there already --- feel free to peek at the CVS server or
a nightly snapshot tarball to make sure.
regards, tom lane
Ned Wolpert <ned.wolpert@knowledgenet.com> writes:
> (You patched this about two months ago.) Specifically, the 1.11 version of
> jdbc2/PreparedStatment.java file has the patch, but the 7.1.3 released does
> not. How do we propragate patches into the main branch for releasing?
At this point, we don't; it's quite unlikely that there will be a 7.1.4,
considering that we hope to be in 7.2 beta within a month.
As far as JDBC goes, lots of people seem to be using CVS snapshots quite
happily, so I'm not sure an official back-patch is needed anyway.
regards, tom lane
-- 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
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
* Bruce Momjian <pgman@candle.pha.pa.us> wrote:
|
| 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.
I've mentioned it before, but I really think it would nice to decouple the
release cycles of the core engine from the interfaces. Make them separate
projects.
Just my kroner,
Gunnar
--
Gunnar Rønning - gunnar@polygnosis.com
Senior Consultant, Polygnosis AS, http://www.polygnosis.com/
>> I've mentioned it before, but I really think it would nice to decouple the
>> release cycles of the core engine from the interfaces. Make them separate
>> projects.
> We have sort of done that now by pushing everyone to the CVS version.
This makes some sense to me for ODBC and JDBC, which are large and
complex enough to deserve the label of separate projects; and moreover
they go out of their way to work with multiple server releases. I'm not
sure it's appropriate for any of the other interface libraries, though.
IIRC, at one time ODBC *was* a separate project, and we decided that
that wasn't working too well. Anyone recall the reasons we pulled it
into the main CVS tree? Wouldn't do to make the same mistakes twice...
regards, tom lane
* Bruce Momjian <pgman@candle.pha.pa.us> wrote: | | > release cycles of the core engine from the interfaces. Make them separate | > projects. | | We have sort of done that now by pushing everyone to the CVS version. ;-) I know. The problem is that I wouldn't trust a CVS version of the JDBC driver in any production environment. I want a released version ;-) Maybe something for RedHat to pickup ? -- Gunnar Rønning - gunnar@polygnosis.com Senior Consultant, Polygnosis AS, http://www.polygnosis.com/
I personally am against the idea of having the JDBC driver on a completely different schedule from the server. I beleive that many people like the binary distributions of Postgres. And that the binary distributions should include the jdbc driver. Since the binary distributions are tied to server release versions there needs to be high quality releases of the jdbc code that correspond to each server release. Another reason is that there are often server changes that cause older versions of the driver not to work with newer versions of the database (while these should be avoided, they happen). Therefore if the driver version isn't tied to the server version, there will be some window where there isn't a JDBC driver that works with the latest server release. Now having said that, there isn't any reason that the jdbc code can't be released more frequently than the server. But without a lot more developers working on the JDBC code, that isn't going to happen. It is difficult enough to keep up with the changes in the server with the current number of jdbc developers. (not that I am complaining about the rapid advancement of server functionality mind you :-) thanks, --Barry Gunnar Rønning wrote: > * Bruce Momjian <pgman@candle.pha.pa.us> wrote: > | > | 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. > > I've mentioned it before, but I really think it would nice to decouple the > release cycles of the core engine from the interfaces. Make them separate > projects. > > Just my kroner, > Gunnar >
* Barry Lind <barry@xythos.com> wrote: | | | Now having said that, there isn't any reason that the jdbc code can't | be released more frequently than the server. But without a lot more Maybe there could be sub releases or something, e.g. jdbc version 7.1.2_004 begin release number 4 of the JDBC driver for 7.1.2. We can't keep recommending people to use CVS tip and if we cannot release a quality version of the driver synchronized with the release of the core server, then we will need another release cycle. -- Gunnar Rønning - gunnar@polygnosis.com Senior Consultant, Polygnosis AS, http://www.polygnosis.com/
> * Barry Lind <barry@xythos.com> wrote: > | > | > | Now having said that, there isn't any reason that the jdbc code can't > | be released more frequently than the server. But without a lot more > > Maybe there could be sub releases or something, e.g. jdbc version 7.1.2_004 > begin release number 4 of the JDBC driver for 7.1.2. We can't keep > recommending people to use CVS tip and if we cannot release a quality > version of the driver synchronized with the release of the core server, then > we will need another release cycle. 7.1.X was an aberation for jdbc because Peter Mount was unavailable and we didn't have jdbc people working on it yet. Let's see how 7.2 and 7.3 go with jdbc. -- 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
* Bruce Momjian <pgman@candle.pha.pa.us> wrote: | | 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. > I've mentioned it before, but I really think it would nice to decouple the > release cycles of the core engine from the interfaces. Make them separate > projects. > > Just my kroner, > Gunnar JDBC never really followed the release cycled exactly any how. It's only since I had to step back from development that it became more rigid. Peter -- Peter Mount peter@retep.org.uk PostgreSQL JDBC Driver: http://www.retep.org.uk/postgres/ RetepPDF PDF library for Java: http://www.retep.org.uk/pdf/
Tom Lane writes: > IIRC, at one time ODBC *was* a separate project, and we decided that > that wasn't working too well. Anyone recall the reasons we pulled it > into the main CVS tree? Wouldn't do to make the same mistakes twice... The ODBC driver was created by someone else (Insight something). They stopped development and someone had to take it up. -- Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
Quoting Peter Eisentraut <peter_e@gmx.net>: > Tom Lane writes: > > > IIRC, at one time ODBC *was* a separate project, and we decided that > > that wasn't working too well. Anyone recall the reasons we pulled it > > into the main CVS tree? Wouldn't do to make the same mistakes > twice... > > The ODBC driver was created by someone else (Insight something). They > stopped development and someone had to take it up. Same with JDBC. It was originally two separate projects when I picked them up and brought them into the main CVS tree. Peter -- Peter Mount peter@retep.org.uk PostgreSQL JDBC Driver: http://www.retep.org.uk/postgres/ RetepPDF PDF library for Java: http://www.retep.org.uk/pdf/
I agree with Bruce. I think we are in good shape for 7.2. As long as there is an active developer community working on maintaining and upgrading the code base there shouldn't be problems. Once we get the jdbc.postgresql.org website updated then there can be an official place to post patches/updated drivers on a more frequent schedule than the server patch releases if necessary. Although realistically the same level of control/caution should be used in accepting patches into the current release as there is being used for the rest of the product (i.e. it needs to be a high priority bug and a low risk fix to risk destabilizing a production set of code). Even in 7.1 there were some jdbc fixes that made it into 7.1.2, and quite frankly I haven't seen anything since 7.1.2 that I would have considered a candidate for patching into 7.1.3 based on the criteria I feel should be applied. The 7.1.2 driver is IMHO high quality, and I use it in production environments. Part of the problem I see is a too frequent habit of telling users on this list who are having problems simply to get the latest code from the truck. We should instead be telling them to get the latest released code ie. 7.1.2 or 7.1.3. thanks, --Barry Bruce Momjian wrote: >>* Barry Lind <barry@xythos.com> wrote: >>| >>| >>| Now having said that, there isn't any reason that the jdbc code can't >>| be released more frequently than the server. But without a lot more >> >>Maybe there could be sub releases or something, e.g. jdbc version 7.1.2_004 >>begin release number 4 of the JDBC driver for 7.1.2. We can't keep >>recommending people to use CVS tip and if we cannot release a quality >>version of the driver synchronized with the release of the core server, then >>we will need another release cycle. >> > > 7.1.X was an aberation for jdbc because Peter Mount was unavailable and > we didn't have jdbc people working on it yet. Let's see how 7.2 and 7.3 > go with jdbc. > >
> > I agree with Bruce. I think we are in good shape for 7.2. As long as > there is an active developer community working on maintaining and > upgrading the code base there shouldn't be problems. > > Once we get the jdbc.postgresql.org website updated then there can be an > official place to post patches/updated drivers on a more frequent > schedule than the server patch releases if necessary. > > Although realistically the same level of control/caution should be used > in accepting patches into the current release as there is being used for > the rest of the product (i.e. it needs to be a high priority bug and a > low risk fix to risk destabilizing a production set of code). Even in > 7.1 there were some jdbc fixes that made it into 7.1.2, and quite > frankly I haven't seen anything since 7.1.2 that I would have considered > a candidate for patching into 7.1.3 based on the criteria I feel should > be applied. The 7.1.2 driver is IMHO high quality, and I use it in > production environments. > > > Part of the problem I see is a too frequent habit of telling users on > this list who are having problems simply to get the latest code from the > truck. We should instead be telling them to get the latest released > code ie. 7.1.2 or 7.1.3. Agreed. Part of the problem is that while 7.1.2 jdbc works well for most uses, it has some gaping holes especially with system catalog information, and there are so many that we just tell people to get the CVS version. -- 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 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. -----Original Message----- From: pgsql-jdbc-owner@postgresql.org [mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Bruce Momjian Sent: August 22, 2001 2:18 PM To: Barry Lind Cc: pgsql-jdbc@postgresql.org; Gunnar Ronning Subject: Re: [JDBC] Re: Couple of patches for jdbc driver > > I agree with Bruce. I think we are in good shape for 7.2. As long as > there is an active developer community working on maintaining and > upgrading the code base there shouldn't be problems. > > Once we get the jdbc.postgresql.org website updated then there can be > an > official place to post patches/updated drivers on a more frequent > schedule than the server patch releases if necessary. > > Although realistically the same level of control/caution should be > used > in accepting patches into the current release as there is being used for > the rest of the product (i.e. it needs to be a high priority bug and a > low risk fix to risk destabilizing a production set of code). Even in > 7.1 there were some jdbc fixes that made it into 7.1.2, and quite > frankly I haven't seen anything since 7.1.2 that I would have considered > a candidate for patching into 7.1.3 based on the criteria I feel should > be applied. The 7.1.2 driver is IMHO high quality, and I use it in > production environments. > > > Part of the problem I see is a too frequent habit of telling users on > this list who are having problems simply to get the latest code from the > truck. We should instead be telling them to get the latest released > code ie. 7.1.2 or 7.1.3. Agreed. Part of the problem is that while 7.1.2 jdbc works well for most uses, it has some gaping holes especially with system catalog information, and there are so many that we just tell people to get the CVS version. -- 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 ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
> 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 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
Quoting Bruce Momjian <pgman@candle.pha.pa.us>: > > 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? Peter -- Peter Mount peter@retep.org.uk PostgreSQL JDBC Driver: http://www.retep.org.uk/postgres/ RetepPDF PDF library for Java: http://www.retep.org.uk/pdf/
> Quoting Bruce Momjian <pgman@candle.pha.pa.us>: > > > > 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 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
> 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 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
Bruce, I can try to fill in whatever I can. Where is it? Can you fill in as much as you can? Dave -----Original Message----- From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] Sent: August 23, 2001 10:46 AM To: Peter T Mount Cc: Dave@micro-automation.net; pgsql-jdbc@postgresql.org Subject: Re: [JDBC] Re: Couple of patches for jdbc driver > Quoting Bruce Momjian <pgman@candle.pha.pa.us>: > > > > 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 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
On Thu, 23 Aug 2001 10:46:18 -0400 (EDT), Bruce Momjian wrote: >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 think you should require us to post a release note with every patch. That would make great documentation for reviewing and evaluating the patch as well. Regards, René Pijlman
> On Thu, 23 Aug 2001 10:46:18 -0400 (EDT), Bruce Momjian wrote: > >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 think you should require us to post a release note with every > patch. > > That would make great documentation for reviewing and evaluating > the patch as well. Uh, I guess. We don't require that for others. We go through the list of items before each release. -- 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
So going forward, whose responsibility is it to maintain this file? Is it the responsibility of the person submitting the patch (i.e. each patch should contain an update to CHANGELOG), or is it the responsibility of the person applying the patch? thanks, --Barry Bruce Momjian wrote: >>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. > > >
> So going forward, whose responsibility is it to maintain this file? Is > it the responsibility of the person submitting the patch (i.e. each > patch should contain an update to CHANGELOG), or is it the > responsibility of the person applying the patch? > I think it has to be done at release time, like HISTORY. -- 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
> * Bruce Momjian <pgman@candle.pha.pa.us> wrote: > | > | 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. > > I've mentioned it before, but I really think it would nice to decouple the > release cycles of the core engine from the interfaces. Make them separate > projects. We have sort of done that now by pushing everyone to the CVS version. -- 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
On Thu, Aug 23, 2001 at 06:42:56PM -0700, Barry Lind wrote: > So going forward, whose responsibility is it to maintain this file? Is > it the responsibility of the person submitting the patch (i.e. each > patch should contain an update to CHANGELOG), or is it the > responsibility of the person applying the patch? I think that whenever a person submits a patch, they should include an associated changelog entry. It's quite easy to do with emacs (M-x add-change-log-entry). The CVS commit message can then be taken/adapted from the changelog patch. -- Liam Stewart :: Red Hat Canada, Ltd. :: liams@redhat.com