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? As you see, I prefer a separate namespace for SQLGetInfo() constants. Why? 1) I like namespaces ;-) 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? Steffen
