On Thu, Feb 07, 2002 at 01:52:39AM +0000, Tim Bunce wrote:
> FYI, here's how things have worked out...

I'll take the silence as agreement :)

>     =item C<get_info> I<NEW>
>      
>     B<Warning:> This method is experimental and may change.
>      
>       $value = $dbh->get_info( $info_type );
>      
>     Returns information about the implementation, i.e. driver and data
>     source capabilities, restrictions etc. It returns C<undef> for
>     unknown or unimplemented information types. For example:
>      
>       $database_version  = $dbh->get_info(  18 ); # SQL_DBMS_VER
>       $max_select_tables = $dbh->get_info( 106 ); # SQL_MAXIMUM_TABLES_IN_SELECT
>      
>     See L</"Standards Reference Information"> for more detailed information
>     about the information types and their meanings and possible return values.
> 
>     The DBI curently doesn't provide a name to number mapping for the
>     information type codes or the results. Applications are expected to use
>     the integer values directly, with the name in a comment, or define
>     their own named values using something like the L<constant> pragma.
>      
>     Because some DBI methods make use of get_info(), drivers are strongly
>     encouraged to support I<at least> the following very minimal set
>     of information types to ensure the DBI itself works properly:
>      
>      Type  Name                        Example A     Example B
>      ----  --------------------------  ------------  ------------
>        17  SQL_DBMS_NAME               'ACCESS'      'Oracle'
>        18  SQL_DBMS_VER                '03.50.0000'  '08.01.0721'
>        29  SQL_IDENTIFIER_QUOTE_CHAR   '`'           '"'
>        41  SQL_CATALOG_NAME_SEPARATOR  '.'           '@'
>       114  SQL_CATALOG_LOCATION        1             2

I thought about mandating a longer list, but the list would have
been very long and very hard to define the boundaries for.
This list is a) much easier to justify, and b) so small that any
self-respecting driver author would want to add more to it :)

Almost all of the get_info info is trivial to either hard-code or
fetch from the server so I really hope driver authors implement
this soon (modeled on Steffen Goeldner's great work posted here).

I should strees that ideally the results from get_info() for any
given database-specific driver should ideally match the results
from DBD::ODBC's get_info() when connected to the same database.

Tim.

p.s. Steffen, any chance you could produce a chunk of code that'll
connect to a DSN (specified on the command line), query all the
get_info values and dump the results to stdout as a DBD::<foo>::GetInfo
module?  Shouldn't be a big modification from the scripts you've
obviously developed already. It would obviously be a big help
to many driver authors.

Reply via email to