Re: foreign_key_info() nits

On 16/11/14 23:59, Kurt Starsinic wrote:
> Hi all,
>
> I've been using DBI with DBD::Sybase and SQL Server, and discovered a
> couple of issues. I will be happy to offer a patch if I can get some
> consensus on what the correct resolutions are:
>
> The DBI docs say that foreign_key_info() can take from 3 to 7
> arguments, but the code demands 6 or 7 (even though many of the
> arguments can be undef). My opinion is that the docs are good and the
> code is broken. Any objections on this point?

The docs say:

   $sth = $dbh->foreign_key_info( $pk_catalog, $pk_schema, $pk_table
                                , $fk_catalog, $fk_schema, $fk_table );

Perhaps you are referring to "If both PKT and FKT are given" or the examples:

   $sth = $dbh->foreign_key_info( undef, $user, 'master');
   $sth = $dbh->foreign_key_info( undef, undef,   undef , undef, $user, 'detail');
   $sth = $dbh->foreign_key_info( undef, $user, 'master', undef, $user, 'detail');

The addition of \%attr on the end of foreign_key_info is probably what is dictating the minimum of 6 so I think the example with 3 arguments is probably wrong. Also the ODBC API for SQLForeignKeys takes the same 6 arguments.

> Also, at least with SQL Server, foreign_key_info() returns columns
> named [FP]KTABLE_OWNER and [FP]KTABLE_QUALIFIER instead of
> [FP]KTABLE_SCHEMA and [FP]KTABLE_CAT. I think the driver should
> rewrite the column names. Does anybody disagree?

They are the old ODBC 2 names for the columns. You can certainly get those with DBD::ODBC with very old drivers. The ODBC docs say:

"The following columns have been renamed for ODBC 3.x. The column name changes do not affect backward compatibility because applications bind by column number."

As the DBD::ODBC maintainer I would prefer not to have to map ODBC 2 names to 3 - it would set a precedent that would lead to many other changes.

>
> Thanks, Kurt Starsinic
>

Martin