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

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Barry Lind <barry(at)xythos(dot)com>
Cc: Rene Pijlman <rpijlman(at)wanadoo(dot)nl>, pgsql-patches(at)postgresql(dot)org
Subject: Re: Re: [JDBC] JDBC pg_description update needed for CVS tip
Date: 2001-08-17 17:34:32
Message-ID: 200108171734.f7HHYW404516@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-jdbc pgsql-patches


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(at)postgresql(dot)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(at)postgresql(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Barry Lind 2001-08-17 17:37:18 Re: encoding names
Previous Message Leandro Saad 2001-08-17 17:32:05 DB size

Browse pgsql-jdbc by date

  From Date Subject
Next Message Dave Cramer 2001-08-17 17:52:26 RE: Unable to connect to database
Previous Message Rene Pijlman 2001-08-17 15:16:37 Re: postgresql ID

Browse pgsql-patches by date

  From Date Subject
Next Message Barry Lind 2001-08-17 17:37:18 Re: encoding names
Previous Message Peter Eisentraut 2001-08-17 16:11:00 Re: encoding names