Thread: DatabaseMetaData oddities

DatabaseMetaData oddities

From
Oliver Jowett
Date:
These patches fix some oddities in the postgresql JDBC driver's
implementation of DatabaseMetaData.

The patches are against recent CVS; I've used them against a 7.2.3 server
and the current CVS (7.4devel) server successfully.

Quick summaries:

  pgsql_getTypeInfo-ordering.patch:
     correct ordering of results from DatabaseMetaData.getTypeInfo().

  pgsql_more-jdbc3-metadata.patch:
     implement some unimplemented JDBC3 DatabaseMetaData methods.

  pgsql_reduce-table-name-length.patch:
     reduce getMaxTableNameLength() by 5 to account for the server
     appending _pkey to generate an index name.

and one non-metadata patch:

  pgsql_null-statement-tostring.patch:
     avoid NullPointerException in AbstractJdbc1Statement.toString()

Hopefully these are useful to someone..

-O

Attachment

Re: DatabaseMetaData oddities

From
Oliver Jowett
Date:
Is there any interest in these patches? Should I resend them elsewhere?

-O

----- Forwarded message from Oliver Jowett <oliver@opencloud.com> -----

Date: Tue, 17 Dec 2002 19:01:33 +1300
To: pgsql-jdbc@postgresql.org
Subject: [JDBC] DatabaseMetaData oddities
From: Oliver Jowett <oliver@opencloud.com>

These patches fix some oddities in the postgresql JDBC driver's
implementation of DatabaseMetaData.

The patches are against recent CVS; I've used them against a 7.2.3 server
and the current CVS (7.4devel) server successfully.

Quick summaries:

  pgsql_getTypeInfo-ordering.patch:
     correct ordering of results from DatabaseMetaData.getTypeInfo().

  pgsql_more-jdbc3-metadata.patch:
     implement some unimplemented JDBC3 DatabaseMetaData methods.

  pgsql_reduce-table-name-length.patch:
     reduce getMaxTableNameLength() by 5 to account for the server
     appending _pkey to generate an index name.

and one non-metadata patch:

  pgsql_null-statement-tostring.patch:
     avoid NullPointerException in AbstractJdbc1Statement.toString()

Hopefully these are useful to someone..

-O

[...]

----- End forwarded message -----

Re: DatabaseMetaData oddities

From
Bruce Momjian
Date:
Uh, we have two very dedicated jdbc patch appliers, Dave and Barry.  Guys?

---------------------------------------------------------------------------

Oliver Jowett wrote:
> Is there any interest in these patches? Should I resend them elsewhere?
>
> -O
>
> ----- Forwarded message from Oliver Jowett <oliver@opencloud.com> -----
>
> Date: Tue, 17 Dec 2002 19:01:33 +1300
> To: pgsql-jdbc@postgresql.org
> Subject: [JDBC] DatabaseMetaData oddities
> From: Oliver Jowett <oliver@opencloud.com>
>
> These patches fix some oddities in the postgresql JDBC driver's
> implementation of DatabaseMetaData.
>
> The patches are against recent CVS; I've used them against a 7.2.3 server
> and the current CVS (7.4devel) server successfully.
>
> Quick summaries:
>
>   pgsql_getTypeInfo-ordering.patch:
>      correct ordering of results from DatabaseMetaData.getTypeInfo().
>
>   pgsql_more-jdbc3-metadata.patch:
>      implement some unimplemented JDBC3 DatabaseMetaData methods.
>
>   pgsql_reduce-table-name-length.patch:
>      reduce getMaxTableNameLength() by 5 to account for the server
>      appending _pkey to generate an index name.
>
> and one non-metadata patch:
>
>   pgsql_null-statement-tostring.patch:
>      avoid NullPointerException in AbstractJdbc1Statement.toString()
>
> Hopefully these are useful to someone..
>
> -O
>
> [...]
>
> ----- End forwarded message -----
>
> ---------------------------(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
>

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Re: DatabaseMetaData oddities

From
Barry Lind
Date:
Oliver,

The patch is still in my queue and not lost.  However I am terribly behind.

--Barry


Oliver Jowett wrote:
> Is there any interest in these patches? Should I resend them elsewhere?
>
> -O
>
> ----- Forwarded message from Oliver Jowett <oliver@opencloud.com> -----
>
> Date: Tue, 17 Dec 2002 19:01:33 +1300
> To: pgsql-jdbc@postgresql.org
> Subject: [JDBC] DatabaseMetaData oddities
> From: Oliver Jowett <oliver@opencloud.com>
>
> These patches fix some oddities in the postgresql JDBC driver's
> implementation of DatabaseMetaData.
>
> The patches are against recent CVS; I've used them against a 7.2.3 server
> and the current CVS (7.4devel) server successfully.
>
> Quick summaries:
>
>   pgsql_getTypeInfo-ordering.patch:
>      correct ordering of results from DatabaseMetaData.getTypeInfo().
>
>   pgsql_more-jdbc3-metadata.patch:
>      implement some unimplemented JDBC3 DatabaseMetaData methods.
>
>   pgsql_reduce-table-name-length.patch:
>      reduce getMaxTableNameLength() by 5 to account for the server
>      appending _pkey to generate an index name.
>
> and one non-metadata patch:
>
>   pgsql_null-statement-tostring.patch:
>      avoid NullPointerException in AbstractJdbc1Statement.toString()
>
> Hopefully these are useful to someone..
>
> -O
>
> [...]
>
> ----- End forwarded message -----
>
> ---------------------------(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
>




Re: DatabaseMetaData oddities

From
Kris Jurka
Date:
The getTypeInfo patch uses functionality not in Java 1.1 so it cannot be
used in the jdbc1 package.

The JDBC 3 additions look reasonable.

The getMaxTableNameLength patch is not a good idea.  You're changing
something general to fix a very specific problem.  I would recomend using
explicit constraint names or petitioning backend developers to create
non-conflicating auto generated names.

The toString patch is good.  I have changed it to return "" instead of
super.toString() which I believe is a more reasonable value.  I have also
fixed a problem with printing PreparedStatements with some parameters not
set.  Attached is a test case and the new patch.

Kris Jurka


On Mon, 3 Feb 2003, Oliver Jowett wrote:

> Is there any interest in these patches? Should I resend them elsewhere?
>
> -O
>
> ----- Forwarded message from Oliver Jowett <oliver@opencloud.com> -----
>
> Date: Tue, 17 Dec 2002 19:01:33 +1300
> To: pgsql-jdbc@postgresql.org
> Subject: [JDBC] DatabaseMetaData oddities
> From: Oliver Jowett <oliver@opencloud.com>
>
> These patches fix some oddities in the postgresql JDBC driver's
> implementation of DatabaseMetaData.
>
> The patches are against recent CVS; I've used them against a 7.2.3 server
> and the current CVS (7.4devel) server successfully.
>
> Quick summaries:
>
>   pgsql_getTypeInfo-ordering.patch:
>      correct ordering of results from DatabaseMetaData.getTypeInfo().
>
>   pgsql_more-jdbc3-metadata.patch:
>      implement some unimplemented JDBC3 DatabaseMetaData methods.
>
>   pgsql_reduce-table-name-length.patch:
>      reduce getMaxTableNameLength() by 5 to account for the server
>      appending _pkey to generate an index name.
>
> and one non-metadata patch:
>
>   pgsql_null-statement-tostring.patch:
>      avoid NullPointerException in AbstractJdbc1Statement.toString()
>
> Hopefully these are useful to someone..
>
> -O
>
> [...]
>
> ----- End forwarded message -----
>
> ---------------------------(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
>



Attachment

Re: DatabaseMetaData oddities

From
Oliver Jowett
Date:
On Mon, Feb 03, 2003 at 01:00:11PM -0500, Kris Jurka wrote:

> The getTypeInfo patch uses functionality not in Java 1.1 so it cannot be
> used in the jdbc1 package.

I'll look at revising this shortly. What specifically isn't available in 1.1
that the patch used? (the JDK javadoc is fairly useless at giving an
overview of API changes by version).

> The getMaxTableNameLength patch is not a good idea.  You're changing
> something general to fix a very specific problem.  I would recomend using
> explicit constraint names or petitioning backend developers to create
> non-conflicating auto generated names.

Certainly the best fix is to fix the backend.. Where's the best place to
forward this to? I doubt I'll have time to work on this myself.

In the meantime I'll probably use an explicitly named constraint as you
suggest, but this is likely to bite anyone using the metadata values to
generate unique table names.

-O

Re: DatabaseMetaData oddities

From
Kris Jurka
Date:

On Tue, 4 Feb 2003, Oliver Jowett wrote:

> On Mon, Feb 03, 2003 at 01:00:11PM -0500, Kris Jurka wrote:
>
> > The getTypeInfo patch uses functionality not in Java 1.1 so it cannot be
> > used in the jdbc1 package.
>
> I'll look at revising this shortly. What specifically isn't available in 1.1
> that the patch used? (the JDK javadoc is fairly useless at giving an
> overview of API changes by version).
>

Arrays.sort() and Comparators

> > The getMaxTableNameLength patch is not a good idea.  You're changing
> > something general to fix a very specific problem.  I would recomend using
> > explicit constraint names or petitioning backend developers to create
> > non-conflicating auto generated names.
>
> Certainly the best fix is to fix the backend.. Where's the best place to
> forward this to? I doubt I'll have time to work on this myself.
>

pgsql-hackers@postgresql.org


Kris Jurka


Re: DatabaseMetaData oddities

From
Barry Lind
Date:
Patch applied to CVS head.

thanks,
--Barry


Kris Jurka wrote:
> The getTypeInfo patch uses functionality not in Java 1.1 so it cannot be
> used in the jdbc1 package.
>
> The JDBC 3 additions look reasonable.
>
> The getMaxTableNameLength patch is not a good idea.  You're changing
> something general to fix a very specific problem.  I would recomend using
> explicit constraint names or petitioning backend developers to create
> non-conflicating auto generated names.
>
> The toString patch is good.  I have changed it to return "" instead of
> super.toString() which I believe is a more reasonable value.  I have also
> fixed a problem with printing PreparedStatements with some parameters not
> set.  Attached is a test case and the new patch.
>
> Kris Jurka
>
>
> On Mon, 3 Feb 2003, Oliver Jowett wrote:
>
>
>>Is there any interest in these patches? Should I resend them elsewhere?
>>
>>-O
>>
>>----- Forwarded message from Oliver Jowett <oliver@opencloud.com> -----
>>
>>Date: Tue, 17 Dec 2002 19:01:33 +1300
>>To: pgsql-jdbc@postgresql.org
>>Subject: [JDBC] DatabaseMetaData oddities
>>From: Oliver Jowett <oliver@opencloud.com>
>>
>>These patches fix some oddities in the postgresql JDBC driver's
>>implementation of DatabaseMetaData.
>>
>>The patches are against recent CVS; I've used them against a 7.2.3 server
>>and the current CVS (7.4devel) server successfully.
>>
>>Quick summaries:
>>
>>  pgsql_getTypeInfo-ordering.patch:
>>     correct ordering of results from DatabaseMetaData.getTypeInfo().
>>
>>  pgsql_more-jdbc3-metadata.patch:
>>     implement some unimplemented JDBC3 DatabaseMetaData methods.
>>
>>  pgsql_reduce-table-name-length.patch:
>>     reduce getMaxTableNameLength() by 5 to account for the server
>>     appending _pkey to generate an index name.
>>
>>and one non-metadata patch:
>>
>>  pgsql_null-statement-tostring.patch:
>>     avoid NullPointerException in AbstractJdbc1Statement.toString()
>>
>>Hopefully these are useful to someone..
>>
>>-O
>>
>>[...]
>>
>>----- End forwarded message -----
>>
>>---------------------------(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
>>
>
>
>
>
> ------------------------------------------------------------------------
>
> import java.sql.*;
>
> public class StmtNpe {
>
>     public static void main(String args[]) throws Exception {
>         Class.forName("org.postgresql.Driver");
>         Connection conn = DriverManager.getConnection("jdbc:postgresql://localhost:5432/jurka","jurka","");
>         Statement stmt = conn.createStatement();
>         PreparedStatement pstmt = conn.prepareStatement("SELECT A FROM B WHERE c = ? AND d = ?");
> //        pstmt.setInt(1,5);
>         pstmt.setInt(2,4);
>         System.out.println(stmt);
>         System.out.println(pstmt);
>     }
> }
>
>
>
> ------------------------------------------------------------------------
>
> Index: src/interfaces/jdbc/org/postgresql/jdbc1/AbstractJdbc1Statement.java
> ===================================================================
> RCS file: /projects/cvsroot/pgsql-server/src/interfaces/jdbc/org/postgresql/jdbc1/AbstractJdbc1Statement.java,v
> retrieving revision 1.14
> diff -c -r1.14 AbstractJdbc1Statement.java
> *** src/interfaces/jdbc/org/postgresql/jdbc1/AbstractJdbc1Statement.java    2002/11/20 07:34:32    1.14
> --- src/interfaces/jdbc/org/postgresql/jdbc1/AbstractJdbc1Statement.java    2003/02/03 17:59:11
> ***************
> *** 1768,1773 ****
> --- 1768,1776 ----
>        */
>       public String toString()
>       {
> +         if (m_sqlFragments == null)
> +             return "";
> +
>           synchronized (sbuf)
>           {
>               sbuf.setLength(0);
> ***************
> *** 1775,1785 ****
>
>               for (i = 0 ; i < m_binds.length ; ++i)
>               {
>                   if (m_binds[i] == null)
>                       sbuf.append( '?' );
>                   else
> !                     sbuf.append (m_sqlFragments[i]);
> !                 sbuf.append (m_binds[i]);
>               }
>               sbuf.append(m_sqlFragments[m_binds.length]);
>               return sbuf.toString();
> --- 1778,1788 ----
>
>               for (i = 0 ; i < m_binds.length ; ++i)
>               {
> +                 sbuf.append (m_sqlFragments[i]);
>                   if (m_binds[i] == null)
>                       sbuf.append( '?' );
>                   else
> !                     sbuf.append (m_binds[i]);
>               }
>               sbuf.append(m_sqlFragments[m_binds.length]);
>               return sbuf.toString();
>
>
> ------------------------------------------------------------------------
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org



Patches applied Re: DatabaseMetaData oddities

From
Dave Cramer
Date:
The jdbc3 patch was applied by me, and Barry applied the toString patch

Thanks,
Dave
On Mon, 2003-02-03 at 16:02, Oliver Jowett wrote:
> On Mon, Feb 03, 2003 at 01:00:11PM -0500, Kris Jurka wrote:
>
> > The getTypeInfo patch uses functionality not in Java 1.1 so it cannot be
> > used in the jdbc1 package.
>
> I'll look at revising this shortly. What specifically isn't available in 1.1
> that the patch used? (the JDK javadoc is fairly useless at giving an
> overview of API changes by version).
>
> > The getMaxTableNameLength patch is not a good idea.  You're changing
> > something general to fix a very specific problem.  I would recomend using
> > explicit constraint names or petitioning backend developers to create
> > non-conflicating auto generated names.
>
> Certainly the best fix is to fix the backend.. Where's the best place to
> forward this to? I doubt I'll have time to work on this myself.
>
> In the meantime I'll probably use an explicitly named constraint as you
> suggest, but this is likely to bite anyone using the metadata values to
> generate unique table names.
>
> -O
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
--
Dave Cramer <Dave@micro-automation.net>