On Thu, Nov 15, 2001 at 11:52:44AM +0100, Steffen Goeldner wrote: > Metadata routines are used to obtain information about > > - drivers and data sources > - the implementation > - the catalog > > The following table shows these routines defined by SQL/CLI, > ODBC and DBI: > > SQL/CLI ODBC DBI > ----------------- -------------------- --------------------- > - SQLDrivers available_drivers > DataSources SQLDataSources data_sources > ----------------- -------------------- --------------------- > GetFeatureInfo - - > GetFunctions SQLGetFunctions - > GetInfo SQLGetInfo get_info > GetSessionInfo - - > ----------------- -------------------- --------------------- > GetTypeInfo SQLGetTypeInfo type_info > ----------------- -------------------- --------------------- > ColumnPrivileges SQLColumnPrivileges - > Columns SQLColumns column_info > ForeignKeys SQLForeignKeys foreign_key_info > PrimaryKeys SQLPrimaryKeys primary_key_info > - SQLProcedureColumns - > - SQLProcedures - > SpecialColumns SQLSpecialColumns - > - SQLStatistics - > TablePrivileges SQLTablePrivileges - > Tables SQLTables table_info > ----------------- -------------------- --------------------- > > In my opinion, DBI supports the most important routines and I > would assign the missing functions less priorities. > Nevertheless, I like to help on filling the gaps.
Boy, I'm I going to owe you lots of beer! ;-) > Thus I want to know: > > - What should be placed on top of the TODO list? get_info (which doesn't really exist because it's never been documented :) or something like it... I was thinking in terms of simply treating any attribute that begins with SQL_ (and has only capital letters, digits and underscores) as valid for reading and would return undef if not handled by the driver. That way the DBI instantly 'supports' *all* the hundreds of GetInfo values. (That's the kind of cost-benefit trade-off I like :-) Of course, to be practical we'd need to start listing the subset that we recommend drivers do actually support. [And I'd ideally like to be able to detect and warn about misspelt SQL_ attributes. And I'd also like to make it easy to map the names into their official numbers (to make life easier for drivers, especially DBD::ODBC). So I was thinking in terms of having the DBI build process pre-process a list of all SQL_* GetInfo attributes (and possibly *all* SQL_* macros) into some efficiently loadable form.] > - Are there any functions that DBI should never support? Never say never. Tim.
