Re: JDBC Driver Database Meta Data - FK_NAME

For the FK_NAME field in various DatabaseMetaData methods that rely on
getImportedExportedKeys use the actual constraint name (tgconstrname)
not the trigger arguments (tgargs).

Update the DatabaseMetaDataTest because 7.3 returns $n instead of
<unnamed> for unnamed constraints.

Also add a missing drop table in UpdateableResultTest.

Kris Jurka

Patch partially applied.

I didn't apply the changes to AbstractJdbc1DatabaseMetaData.java that
changes the FK_NAME being returned. The existing code is very explicit
that it is trying to return something unique for foreign key name and
the new code doesn't necessarily do that.

Dave,

Do you see any reason why this shouldn't be changed as this patch does?
I am uncomfortable applying this without your review.

thanks,
--Barry

Kris Jurka wrote:
>
> For the FK_NAME field in various DatabaseMetaData methods that rely on
> getImportedExportedKeys use the actual constraint name (tgconstrname)
> not the trigger arguments (tgargs).
>
> Update the DatabaseMetaDataTest because 7.3 returns $n instead of
> <unnamed> for unnamed constraints.
>
> Also add a missing drop table in UpdateableResultTest.
>
> Kris Jurka
>
>
> ------------------------------------------------------------------------
>
> Index: src/interfaces/jdbc/org/postgresql/test/jdbc2/DatabaseMetaDataTest.java
> ===================================================================
> RCS file: /projects/cvsroot/pgsql-server/src/interfaces/jdbc/org/postgresql/test/jdbc2/DatabaseMetaDataTest.java,v
> retrieving revision 1.13
> diff -c -r1.13 DatabaseMetaDataTest.java
> *** src/interfaces/jdbc/org/postgresql/test/jdbc2/DatabaseMetaDataTest.java 2002/09/06 21:23:06 1.13
> --- src/interfaces/jdbc/org/postgresql/test/jdbc2/DatabaseMetaDataTest.java 2002/09/09 20:05:19
> ***************
> *** 264,270 ****
> assertTrue( fkColumnName.equals( "m" ) || fkColumnName.equals( "n" ) ) ;
>
> String fkName = rs.getString( "FK_NAME" );
> ! assertTrue( fkName.equals( "<unnamed>") );
>
> String pkName = rs.getString( "PK_NAME" );
> assertTrue( pkName.equals("vv_pkey") );
> --- 264,274 ----
> assertTrue( fkColumnName.equals( "m" ) || fkColumnName.equals( "n" ) ) ;
>
> String fkName = rs.getString( "FK_NAME" );
> ! if (((org.postgresql.jdbc1.AbstractJdbc1Connection)con1).haveMinimumServerVersion("7.3")) {
> ! assertTrue(fkName.equals("$1"));
> ! } else {
> ! assertTrue( fkName.equals( "<unnamed>") );
> ! }
>
> String pkName = rs.getString( "PK_NAME" );
> assertTrue( pkName.equals("vv_pkey") );
> Index: src/interfaces/jdbc/org/postgresql/test/jdbc2/UpdateableResultTest.java
> ===================================================================
> RCS file: /projects/cvsroot/pgsql-server/src/interfaces/jdbc/org/postgresql/test/jdbc2/UpdateableResultTest.java,v
> retrieving revision 1.6
> diff -c -r1.6 UpdateableResultTest.java
> *** src/interfaces/jdbc/org/postgresql/test/jdbc2/UpdateableResultTest.java 2002/09/06 21:23:06 1.6
> --- src/interfaces/jdbc/org/postgresql/test/jdbc2/UpdateableResultTest.java 2002/09/09 20:05:19
> ***************
> *** 124,129 ****
> --- 124,130 ----
> st.close();
>
> TestUtil.dropTable( con, "updateable" );
> + TestUtil.dropTable( con, "second" );
> TestUtil.closeDB( con );
> }
> catch (Exception ex)
> Index: src/interfaces/jdbc/org/postgresql/jdbc1/AbstractJdbc1DatabaseMetaData.java
> ===================================================================
> RCS file: /projects/cvsroot/pgsql-server/src/interfaces/jdbc/org/postgresql/jdbc1/AbstractJdbc1DatabaseMetaData.java,v
> retrieving revision 1.5
> diff -c -r1.5 AbstractJdbc1DatabaseMetaData.java
> *** src/interfaces/jdbc/org/postgresql/jdbc1/AbstractJdbc1DatabaseMetaData.java 2002/09/08 00:15:28 1.5
> --- src/interfaces/jdbc/org/postgresql/jdbc1/AbstractJdbc1DatabaseMetaData.java 2002/09/09 20:05:20
> ***************
> *** 2630,2636 ****
>
> tuple[2] = rs.getBytes(1); //PKTABLE_NAME
> tuple[6] = rs.getBytes(2); //FKTABLE_NAME
> - String fKeyName = rs.getString(3);
> String updateRule = rs.getString(10);
>
> if (updateRule != null )
> --- 2630,2635 ----
> ***************
> *** 2712,2718 ****
> tuple[7] = fkeyColumn.getBytes(); //FKCOLUMN_NAME
>
> tuple[8] = rs.getBytes(4); //KEY_SEQ
> ! tuple[11] = targs.getBytes(); //FK_NAME this will give us a unique name for the foreign key
> tuple[12] = rs.getBytes(5); //PK_NAME
>
> // DEFERRABILITY
> --- 2711,2717 ----
> tuple[7] = fkeyColumn.getBytes(); //FKCOLUMN_NAME
>
> tuple[8] = rs.getBytes(4); //KEY_SEQ
> ! tuple[11] = rs.getBytes(3); //FK_NAME
> tuple[12] = rs.getBytes(5); //PK_NAME
>
> // DEFERRABILITY
>
>
> ------------------------------------------------------------------------
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster

Barry Lind wrote:
>
> Patch partially applied.
>
> I didn't apply the changes to AbstractJdbc1DatabaseMetaData.java that
> changes the FK_NAME being returned. The existing code is very explicit
> that it is trying to return something unique for foreign key name and
> the new code doesn't necessarily do that.
>
> Dave,
>
> Do you see any reason why this shouldn't be changed as this patch does?
> I am uncomfortable applying this without your review.
>
> thanks,
> --Barry

With the changes to constraint handling in 7.3 this is not an issue
because constraints are required to be unique per table. In <= 7.2 a
unique name would be helpful. I suppose it depends on what the user
plans on doing with the FK_NAME retrieved. If they are simply showing
it uniqueness is good. If they plan on doing ALTER TABLE [FKTABLE_NAME]
DROP CONSTRAINT [FK_NAME] then they need the real constraint name. I
have no strong opinion on the subject because at the moment I am doing
neither.

On an unrelated note I have some other questions about the JDBC driver
in general...

What server versions does the JDBC driver target? Currently it can run
the junit tests successfully on only 7.2 and 7.3. Is it desired to have
these pass (by if(connection.haveMinimumServerVersion("x.y"))
statements) on 7.1, 7.0, 6.5, ...? Even if the tests don't successfully
run against these servers which servers are officially supported? Is
there a minimum set of functionality that should be supported on all
versions?

I'm doing some more work on making DatabaseMetaData queries schema
aware. Would you prefer patches in a one function at a time format or
an all at once approach?

Kris Jurka

Kris,

Give me the schema patches all at once, and I will apply them all at
once, otherwise we get out of sync with the current code.

and many thanks!

Dave
On Wed, 2002-09-11 at 03:19, Kris Jurka wrote:
> Barry Lind wrote:
> >
> > Patch partially applied.
> >
> > I didn't apply the changes to AbstractJdbc1DatabaseMetaData.java that
> > changes the FK_NAME being returned. The existing code is very explicit
> > that it is trying to return something unique for foreign key name and
> > the new code doesn't necessarily do that.
> >
> > Dave,
> >
> > Do you see any reason why this shouldn't be changed as this patch does?
> > I am uncomfortable applying this without your review.
> >
> > thanks,
> > --Barry
>
>
> With the changes to constraint handling in 7.3 this is not an issue
> because constraints are required to be unique per table. In <= 7.2 a
> unique name would be helpful. I suppose it depends on what the user
> plans on doing with the FK_NAME retrieved. If they are simply showing
> it uniqueness is good. If they plan on doing ALTER TABLE [FKTABLE_NAME]
> DROP CONSTRAINT [FK_NAME] then they need the real constraint name. I
> have no strong opinion on the subject because at the moment I am doing
> neither.
>
> On an unrelated note I have some other questions about the JDBC driver
> in general...
>
> What server versions does the JDBC driver target? Currently it can run
> the junit tests successfully on only 7.2 and 7.3. Is it desired to have
> these pass (by if(connection.haveMinimumServerVersion("x.y"))
> statements) on 7.1, 7.0, 6.5, ...? Even if the tests don't successfully
> run against these servers which servers are officially supported? Is
> there a minimum set of functionality that should be supported on all
> versions?
>
> I'm doing some more work on making DatabaseMetaData queries schema
> aware. Would you prefer patches in a one function at a time format or
> an all at once approach?
>
> Kris Jurka
>
>