Thread: DatabaseMetaData oddities
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
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 -----
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
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 >
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
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
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
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
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>