Thread: Re: [JDBC] JDBC pg_description update needed for CVS tip

Re: [JDBC] JDBC pg_description update needed for CVS tip

From

Rene Pijlman

Date:

13 August 2001, 16:59:54

Attached is the patch requested by Tom Lane (see below). It
includes two changes in the JDBC driver:

1) When connected to a backend >= 7.2: use obj_description() and
col_description() instead of direct access to pg_description.

2) In DatabaseMetaData.getTables()/getColumns()/getProcedures():
when there is no comment on the object, return null in the
REMARKS column of the ResultSet, instead of the default string
"no remarks".

Change 2 first appeared as a side-effect of change 1, but it is
actually more compliant with the JDBC spec: "String object
containing an explanatory comment on the table/column/procedure,
which may be null". The default string "no remarks" was strictly
speaking incorrect, as it could not be distinguished from a real
user comment "no remarks". So I removed the default string
completely.

Change 2 might break existing code that doesn't follow the JDBC
spec and isn't prepared to handle a null in the REMARKS column
of getTables()/getColumns()/getProcedures.

Patch tested with jdbc2 against both a 7.1 and a CVS tip
backend. I did not have a jdbc1 environment to build and test
with, but since the touched code is identical in jdbc1 and jdbc2
I don't foresee any problems.

Regards,
René Pijlman

On Fri, 10 Aug 2001 16:08:50 -0400, Tom Lane wrote:
>Would some JDBC hacker develop a patch for the following issue?  The
>change is just barely large enough that I don't want to commit untested
>code for it --- but not having a Java development environment at hand,
>I can't test the updated code.
>
>The problem is in DatabaseMetaData.java (same code in both jdbc1 and
>jdbc2, looks like).  It does direct access to pg_description that isn't
>right anymore.  In getTables, instead of
>
>    java.sql.ResultSet dr = connection.ExecSQL("select description from pg_description where objoid="+r.getInt(2));
>
>it should be
>
>    java.sql.ResultSet dr = connection.ExecSQL("select obj_description("+r.getInt(2)+",'pg_class')");
>
>In getColumns, the change is a little more involved, because
>pg_attribute doesn't have an OID column anymore.  The initial query
>can't fetch a.oid, but should fetch a.attrelid instead, and then the
>pg_description query should become
>
>    java.sql.ResultSet dr = connection.ExecSQL("select col_description("+r.getInt(1)+","+r.getInt(5)+")");
>
>(col_description takes the table OID and the column's attnum).
>
>The reason this is more than a 3-line change is that it should be done
>either the old way or the new way depending on whether server version >=
>7.2 or not, for backwards-compatibility of the driver.
>
>It's possible there are other similar changes needed that I missed in a
>quick lookover.
>
>So, would some enterprising person fix the JDBC code to work with CVS
>tip, and submit a patch?
>
>        thanks, tom lane
>
>---------------------------(end of broadcast)---------------------------
>TIP 3: if posting/reading through Usenet, please send an appropriate
>subscribe-nomail command to majordomo@postgresql.org so that your
>message can get through to the mailing list cleanly

Regards,
René Pijlman

Attachment

patchComment.diff

Re: Re: [JDBC] JDBC pg_description update needed for CVS tip

From

Rene Pijlman

Date:

16 August 2001, 18:00:11

I I'm not mistaken I haven't seen the usual confirmation ("Your
patch has been added to the PostgreSQL unapplied patches list")
for this patch yet.

Is there something wrong with the patch, or is it just waiting
for something or someone?

On Mon, 13 Aug 2001 20:01:24 +0200, I wrote:
>Attached is the patch requested by Tom Lane (see below). It
>includes two changes in the JDBC driver:
>
>1) When connected to a backend >= 7.2: use obj_description() and
>col_description() instead of direct access to pg_description.
>
>2) In DatabaseMetaData.getTables()/getColumns()/getProcedures():
>when there is no comment on the object, return null in the
>REMARKS column of the ResultSet, instead of the default string
>"no remarks".
>
>Change 2 first appeared as a side-effect of change 1, but it is
>actually more compliant with the JDBC spec: "String object
>containing an explanatory comment on the table/column/procedure,
>which may be null". The default string "no remarks" was strictly
>speaking incorrect, as it could not be distinguished from a real
>user comment "no remarks". So I removed the default string
>completely.
>
>Change 2 might break existing code that doesn't follow the JDBC
>spec and isn't prepared to handle a null in the REMARKS column
>of getTables()/getColumns()/getProcedures.
>
>Patch tested with jdbc2 against both a 7.1 and a CVS tip
>backend. I did not have a jdbc1 environment to build and test
>with, but since the touched code is identical in jdbc1 and jdbc2
>I don't foresee any problems.
>
>Regards,
>René Pijlman
>
>On Fri, 10 Aug 2001 16:08:50 -0400, Tom Lane wrote:
>>Would some JDBC hacker develop a patch for the following issue?  The
>>change is just barely large enough that I don't want to commit untested
>>code for it --- but not having a Java development environment at hand,
>>I can't test the updated code.
>>
>>The problem is in DatabaseMetaData.java (same code in both jdbc1 and
>>jdbc2, looks like).  It does direct access to pg_description that isn't
>>right anymore.  In getTables, instead of
>>
>>    java.sql.ResultSet dr = connection.ExecSQL("select description from pg_description where objoid="+r.getInt(2));
>>
>>it should be
>>
>>    java.sql.ResultSet dr = connection.ExecSQL("select obj_description("+r.getInt(2)+",'pg_class')");
>>
>>In getColumns, the change is a little more involved, because
>>pg_attribute doesn't have an OID column anymore.  The initial query
>>can't fetch a.oid, but should fetch a.attrelid instead, and then the
>>pg_description query should become
>>
>>    java.sql.ResultSet dr = connection.ExecSQL("select col_description("+r.getInt(1)+","+r.getInt(5)+")");
>>
>>(col_description takes the table OID and the column's attnum).
>>
>>The reason this is more than a 3-line change is that it should be done
>>either the old way or the new way depending on whether server version >=
>>7.2 or not, for backwards-compatibility of the driver.
>>
>>It's possible there are other similar changes needed that I missed in a
>>quick lookover.
>>
>>So, would some enterprising person fix the JDBC code to work with CVS
>>tip, and submit a patch?
>>
>>        thanks, tom lane
>>
>>---------------------------(end of broadcast)---------------------------
>>TIP 3: if posting/reading through Usenet, please send an appropriate
>>subscribe-nomail command to majordomo@postgresql.org so that your
>>message can get through to the mailing list cleanly
>
>
>Regards,
>René Pijlman


Regards,
René Pijlman

Re: Re: [JDBC] JDBC pg_description update needed for CVS tip

From

Bruce Momjian

Date:

16 August 2001, 20:57:51

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

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

I will try to apply it within the next 48 hours.

> Attached is the patch requested by Tom Lane (see below). It
> includes two changes in the JDBC driver:
>
> 1) When connected to a backend >= 7.2: use obj_description() and
> col_description() instead of direct access to pg_description.
>
> 2) In DatabaseMetaData.getTables()/getColumns()/getProcedures():
> when there is no comment on the object, return null in the
> REMARKS column of the ResultSet, instead of the default string
> "no remarks".
>
> Change 2 first appeared as a side-effect of change 1, but it is
> actually more compliant with the JDBC spec: "String object
> containing an explanatory comment on the table/column/procedure,
> which may be null". The default string "no remarks" was strictly
> speaking incorrect, as it could not be distinguished from a real
> user comment "no remarks". So I removed the default string
> completely.
>
> Change 2 might break existing code that doesn't follow the JDBC
> spec and isn't prepared to handle a null in the REMARKS column
> of getTables()/getColumns()/getProcedures.
>
> Patch tested with jdbc2 against both a 7.1 and a CVS tip
> backend. I did not have a jdbc1 environment to build and test
> with, but since the touched code is identical in jdbc1 and jdbc2
> I don't foresee any problems.
>
> Regards,
> Ren? Pijlman
>
> On Fri, 10 Aug 2001 16:08:50 -0400, Tom Lane wrote:
> >Would some JDBC hacker develop a patch for the following issue?  The
> >change is just barely large enough that I don't want to commit untested
> >code for it --- but not having a Java development environment at hand,
> >I can't test the updated code.
> >
> >The problem is in DatabaseMetaData.java (same code in both jdbc1 and
> >jdbc2, looks like).  It does direct access to pg_description that isn't
> >right anymore.  In getTables, instead of
> >
> >    java.sql.ResultSet dr = connection.ExecSQL("select description from pg_description where objoid="+r.getInt(2));
> >
> >it should be
> >
> >    java.sql.ResultSet dr = connection.ExecSQL("select obj_description("+r.getInt(2)+",'pg_class')");
> >
> >In getColumns, the change is a little more involved, because
> >pg_attribute doesn't have an OID column anymore.  The initial query
> >can't fetch a.oid, but should fetch a.attrelid instead, and then the
> >pg_description query should become
> >
> >    java.sql.ResultSet dr = connection.ExecSQL("select col_description("+r.getInt(1)+","+r.getInt(5)+")");
> >
> >(col_description takes the table OID and the column's attnum).
> >
> >The reason this is more than a 3-line change is that it should be done
> >either the old way or the new way depending on whether server version >=
> >7.2 or not, for backwards-compatibility of the driver.
> >
> >It's possible there are other similar changes needed that I missed in a
> >quick lookover.
> >
> >So, would some enterprising person fix the JDBC code to work with CVS
> >tip, and submit a patch?
> >
> >        thanks, tom lane
> >
> >---------------------------(end of broadcast)---------------------------
> >TIP 3: if posting/reading through Usenet, please send an appropriate
> >subscribe-nomail command to majordomo@postgresql.org so that your
> >message can get through to the mailing list cleanly
>
>
> Regards,
> Ren? Pijlman

[ Attachment, skipping... ]

>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  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

Re: Re: [JDBC] JDBC pg_description update needed for CVS tip

From

Barry Lind

Date:

17 August 2001, 15:14:31

If it helps I reviewed that patch and it looks fine to me.

--Barry

Rene Pijlman wrote:
> I I'm not mistaken I haven't seen the usual confirmation ("Your
> patch has been added to the PostgreSQL unapplied patches list")
> for this patch yet.
>
> Is there something wrong with the patch, or is it just waiting
> for something or someone?
>
> On Mon, 13 Aug 2001 20:01:24 +0200, I wrote:
>
>>Attached is the patch requested by Tom Lane (see below). It
>>includes two changes in the JDBC driver:
>>
>>1) When connected to a backend >= 7.2: use obj_description() and
>>col_description() instead of direct access to pg_description.
>>
>>2) In DatabaseMetaData.getTables()/getColumns()/getProcedures():
>>when there is no comment on the object, return null in the
>>REMARKS column of the ResultSet, instead of the default string
>>"no remarks".
>>
>>Change 2 first appeared as a side-effect of change 1, but it is
>>actually more compliant with the JDBC spec: "String object
>>containing an explanatory comment on the table/column/procedure,
>>which may be null". The default string "no remarks" was strictly
>>speaking incorrect, as it could not be distinguished from a real
>>user comment "no remarks". So I removed the default string
>>completely.
>>
>>Change 2 might break existing code that doesn't follow the JDBC
>>spec and isn't prepared to handle a null in the REMARKS column
>>of getTables()/getColumns()/getProcedures.
>>
>>Patch tested with jdbc2 against both a 7.1 and a CVS tip
>>backend. I did not have a jdbc1 environment to build and test
>>with, but since the touched code is identical in jdbc1 and jdbc2
>>I don't foresee any problems.
>>
>>Regards,
>>René Pijlman
>>
>>On Fri, 10 Aug 2001 16:08:50 -0400, Tom Lane wrote:
>>
>>>Would some JDBC hacker develop a patch for the following issue?  The
>>>change is just barely large enough that I don't want to commit untested
>>>code for it --- but not having a Java development environment at hand,
>>>I can't test the updated code.
>>>
>>>The problem is in DatabaseMetaData.java (same code in both jdbc1 and
>>>jdbc2, looks like).  It does direct access to pg_description that isn't
>>>right anymore.  In getTables, instead of
>>>
>>>    java.sql.ResultSet dr = connection.ExecSQL("select description from pg_description where objoid="+r.getInt(2));
>>>
>>>it should be
>>>
>>>    java.sql.ResultSet dr = connection.ExecSQL("select obj_description("+r.getInt(2)+",'pg_class')");
>>>
>>>In getColumns, the change is a little more involved, because
>>>pg_attribute doesn't have an OID column anymore.  The initial query
>>>can't fetch a.oid, but should fetch a.attrelid instead, and then the
>>>pg_description query should become
>>>
>>>    java.sql.ResultSet dr = connection.ExecSQL("select col_description("+r.getInt(1)+","+r.getInt(5)+")");
>>>
>>>(col_description takes the table OID and the column's attnum).
>>>
>>>The reason this is more than a 3-line change is that it should be done
>>>either the old way or the new way depending on whether server version >=
>>>7.2 or not, for backwards-compatibility of the driver.
>>>
>>>It's possible there are other similar changes needed that I missed in a
>>>quick lookover.
>>>
>>>So, would some enterprising person fix the JDBC code to work with CVS
>>>tip, and submit a patch?
>>>
>>>        thanks, tom lane
>>>
>>>---------------------------(end of broadcast)---------------------------
>>>TIP 3: if posting/reading through Usenet, please send an appropriate
>>>subscribe-nomail command to majordomo@postgresql.org so that your
>>>message can get through to the mailing list cleanly
>>>
>>
>>Regards,
>>René Pijlman
>>
>
>
> Regards,
> René Pijlman
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>
>

Re: Re: [JDBC] JDBC pg_description update needed for CVS tip

From

Bruce Momjian

Date:

17 August 2001, 16:34:40

This patch was applied a few hours ago.

> If it helps I reviewed that patch and it looks fine to me.
>
> --Barry
>
> Rene Pijlman wrote:
> > I I'm not mistaken I haven't seen the usual confirmation ("Your
> > patch has been added to the PostgreSQL unapplied patches list")
> > for this patch yet.
> >
> > Is there something wrong with the patch, or is it just waiting
> > for something or someone?
> >
> > On Mon, 13 Aug 2001 20:01:24 +0200, I wrote:
> >
> >>Attached is the patch requested by Tom Lane (see below). It
> >>includes two changes in the JDBC driver:
> >>
> >>1) When connected to a backend >= 7.2: use obj_description() and
> >>col_description() instead of direct access to pg_description.
> >>
> >>2) In DatabaseMetaData.getTables()/getColumns()/getProcedures():
> >>when there is no comment on the object, return null in the
> >>REMARKS column of the ResultSet, instead of the default string
> >>"no remarks".
> >>
> >>Change 2 first appeared as a side-effect of change 1, but it is
> >>actually more compliant with the JDBC spec: "String object
> >>containing an explanatory comment on the table/column/procedure,
> >>which may be null". The default string "no remarks" was strictly
> >>speaking incorrect, as it could not be distinguished from a real
> >>user comment "no remarks". So I removed the default string
> >>completely.
> >>
> >>Change 2 might break existing code that doesn't follow the JDBC
> >>spec and isn't prepared to handle a null in the REMARKS column
> >>of getTables()/getColumns()/getProcedures.
> >>
> >>Patch tested with jdbc2 against both a 7.1 and a CVS tip
> >>backend. I did not have a jdbc1 environment to build and test
> >>with, but since the touched code is identical in jdbc1 and jdbc2
> >>I don't foresee any problems.
> >>
> >>Regards,
> >>Ren? Pijlman
> >>
> >>On Fri, 10 Aug 2001 16:08:50 -0400, Tom Lane wrote:
> >>
> >>>Would some JDBC hacker develop a patch for the following issue?  The
> >>>change is just barely large enough that I don't want to commit untested
> >>>code for it --- but not having a Java development environment at hand,
> >>>I can't test the updated code.
> >>>
> >>>The problem is in DatabaseMetaData.java (same code in both jdbc1 and
> >>>jdbc2, looks like).  It does direct access to pg_description that isn't
> >>>right anymore.  In getTables, instead of
> >>>
> >>>    java.sql.ResultSet dr = connection.ExecSQL("select description from pg_description where
objoid="+r.getInt(2));
> >>>
> >>>it should be
> >>>
> >>>    java.sql.ResultSet dr = connection.ExecSQL("select obj_description("+r.getInt(2)+",'pg_class')");
> >>>
> >>>In getColumns, the change is a little more involved, because
> >>>pg_attribute doesn't have an OID column anymore.  The initial query
> >>>can't fetch a.oid, but should fetch a.attrelid instead, and then the
> >>>pg_description query should become
> >>>
> >>>    java.sql.ResultSet dr = connection.ExecSQL("select col_description("+r.getInt(1)+","+r.getInt(5)+")");
> >>>
> >>>(col_description takes the table OID and the column's attnum).
> >>>
> >>>The reason this is more than a 3-line change is that it should be done
> >>>either the old way or the new way depending on whether server version >=
> >>>7.2 or not, for backwards-compatibility of the driver.
> >>>
> >>>It's possible there are other similar changes needed that I missed in a
> >>>quick lookover.
> >>>
> >>>So, would some enterprising person fix the JDBC code to work with CVS
> >>>tip, and submit a patch?
> >>>
> >>>        thanks, tom lane
> >>>
> >>>---------------------------(end of broadcast)---------------------------
> >>>TIP 3: if posting/reading through Usenet, please send an appropriate
> >>>subscribe-nomail command to majordomo@postgresql.org so that your
> >>>message can get through to the mailing list cleanly
> >>>
> >>
> >>Regards,
> >>Ren? Pijlman
> >>
> >
> >
> > Regards,
> > Ren? Pijlman
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
> >
> >
>
>
>
> ---------------------------(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

Re: Re: [JDBC] JDBC pg_description update needed for CVS tip

From

Bruce Momjian

Date:

17 August 2001, 22:12:06

Applied.  Thanks.

> Attached is the patch requested by Tom Lane (see below). It
> includes two changes in the JDBC driver:
>
> 1) When connected to a backend >= 7.2: use obj_description() and
> col_description() instead of direct access to pg_description.
>
> 2) In DatabaseMetaData.getTables()/getColumns()/getProcedures():
> when there is no comment on the object, return null in the
> REMARKS column of the ResultSet, instead of the default string
> "no remarks".
>
> Change 2 first appeared as a side-effect of change 1, but it is
> actually more compliant with the JDBC spec: "String object
> containing an explanatory comment on the table/column/procedure,
> which may be null". The default string "no remarks" was strictly
> speaking incorrect, as it could not be distinguished from a real
> user comment "no remarks". So I removed the default string
> completely.
>
> Change 2 might break existing code that doesn't follow the JDBC
> spec and isn't prepared to handle a null in the REMARKS column
> of getTables()/getColumns()/getProcedures.
>
> Patch tested with jdbc2 against both a 7.1 and a CVS tip
> backend. I did not have a jdbc1 environment to build and test
> with, but since the touched code is identical in jdbc1 and jdbc2
> I don't foresee any problems.
>
> Regards,
> Ren? Pijlman
>
> On Fri, 10 Aug 2001 16:08:50 -0400, Tom Lane wrote:
> >Would some JDBC hacker develop a patch for the following issue?  The
> >change is just barely large enough that I don't want to commit untested
> >code for it --- but not having a Java development environment at hand,
> >I can't test the updated code.
> >
> >The problem is in DatabaseMetaData.java (same code in both jdbc1 and
> >jdbc2, looks like).  It does direct access to pg_description that isn't
> >right anymore.  In getTables, instead of
> >
> >    java.sql.ResultSet dr = connection.ExecSQL("select description from pg_description where objoid="+r.getInt(2));
> >
> >it should be
> >
> >    java.sql.ResultSet dr = connection.ExecSQL("select obj_description("+r.getInt(2)+",'pg_class')");
> >
> >In getColumns, the change is a little more involved, because
> >pg_attribute doesn't have an OID column anymore.  The initial query
> >can't fetch a.oid, but should fetch a.attrelid instead, and then the
> >pg_description query should become
> >
> >    java.sql.ResultSet dr = connection.ExecSQL("select col_description("+r.getInt(1)+","+r.getInt(5)+")");
> >
> >(col_description takes the table OID and the column's attnum).
> >
> >The reason this is more than a 3-line change is that it should be done
> >either the old way or the new way depending on whether server version >=
> >7.2 or not, for backwards-compatibility of the driver.
> >
> >It's possible there are other similar changes needed that I missed in a
> >quick lookover.
> >
> >So, would some enterprising person fix the JDBC code to work with CVS
> >tip, and submit a patch?
> >
> >        thanks, tom lane
> >
> >---------------------------(end of broadcast)---------------------------
> >TIP 3: if posting/reading through Usenet, please send an appropriate
> >subscribe-nomail command to majordomo@postgresql.org so that your
> >message can get through to the mailing list cleanly
>
>
> Regards,
> Ren? Pijlman

[ Attachment, skipping... ]

>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  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