On Fri, Nov 23, 2001 at 03:16:32PM +0100, Steffen Goeldner wrote: > Tim Bunce wrote: > (see <http:[EMAIL PROTECTED]/msg00499.html>) > > > > [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.] > > Recently, I extented the list of datatype codes for DBI, see: > > <http:[EMAIL PROTECTED]/msg00483.html> > > These constants are defined via ALIAS. I'm really not very familiar > with XS, but if this is such an 'efficiently loadable form', then > the same approach could be applied to the SQLGetInfo() constants: > > MODULE = DBI PACKAGE = DBI::Const::GetInfo > > I32 > constant() > PROTOTYPE: > ALIAS: > SQL_MAXIMUM_DRIVER_CONNECTIONS = SQL_MAXIMUM_DRIVER_CONNECTIONS > SQL_MAXIMUM_CONCURRENT_ACTIVITIES = SQL_MAXIMUM_CONCURRENT_ACTIVITIES > ... > SQL_OJ_CAPABILITIES = SQL_OJ_CAPABILITIES > CODE: > RETVAL = ix; > OUTPUT: > RETVAL > > > Or is this the wrong track?
It could. The downside is more expensive DBI startup. > As you see, I prefer a separate namespace for SQLGetInfo() constants. > Why? > > 1) I like namespaces ;-) Me too. Namespaces are good. > 2) I encountered some difficulties if namespaces are not preserved, > see e.g.: > <http:[EMAIL PROTECTED]/msg00538.html> > 3) The requirement to list known constants is stated in > DBI-1.20/ToDo: > > > Consider making all SQL_ known to the DBI. Want to check for > > valid spelling. Also would like C<exists $h->{Attrib}> to > > work. Maybe auto load a module that defines a private hash > > that just serves to list known attributes. > > Or DBI->SQL_FOO and/or DBI::SQL_FOO. > > With %DBI::Const::GetInfo::, we would have a hash for that > purpose. > > Opinions? As internal implementation, fine. As user interface, probably not. I think I'd rather stick with the "use DBI qw(...)", but allow things like "use DBI qw(:get_info_subsetfoo)". Few applications will use more than a handful of distinct GetInfo calls anyway. Another issue here is the difference between $h->{SQL_FOO} and $h->{SQL_FOO()} (or $h->{+SQL_FOO} etc) Driver code should naturally be written to use the numbers. But users are _bound_ to use the $h->{SQL_FOO} form so there needs to be an efficient mechanism to transparently convert the name to a number. Tim.
