On Tue, Jan 29, 2002 at 02:36:54PM -0800, Jeff Zucker wrote:
> I only have six questions so far :-)
>
> 1. Is this a good summary of our story to date?
>
> * There is (will be) a database handle method in DBI,
> get_info(), that will call a get_info() method in each DBD
> that supports it and return the equivalent for that driver of
> what DBD::ODBC now returns with $dbh->func( $info_type,
> 'GetInfo').
Yes. (It's been in the DBI for a while but always just returns undef currently.)
> * The same information will be available via a database handle
> attribute $value = $dbh->{ $info_type }.
No. (That was the original plan but I've changed my mind.)
> * The $info_type parameter is an integer. These integers can be
> found in the docs for ODBC or SQL/CLI
Yes.
> or in the DBI %GetInfo
> which has as keys the names of the constants and as values
> their integer code number
> e.g. $GetInfo{SQL_DBMS_NAME} == 17
That bit's undecided at the moment and isn't essential to the plot.
People can just use the (well standardized) numbers for now.
> and therefore DBD::ODBC->get_ifno(17)
> will return 'ACCESS' if MS-Access is being used.
Almost, it's a $dbh method not a static driver method.
> The most recent version of %GetInfo is found in:
> http:[EMAIL PROTECTED]/msg00559.html
There is one there, but you probably want one with a description of
the possible return values.
> 2. I seem to remember a GetInfo( 'All' ) call from somewhere.
> Will that be supported to return a hash of all GetInfo
> values?
Nope.
> 3. Will DBI get_info() support string input e.g. let it figure
> out that get_info('SQL_DBMS_NAME') is the same as
> get_info(17)?
No.
> 4. What about items not in one of the list of constants? Will
> these be handled by something else or can we use
> SQL_USER_DEFINED_FOO or SQL_DBI_FOO settings? For example, I
> don't see a constant for comment styles. Or suppose there
> are extensions e.g. DBD::CSV's case insensitive CLIKE?
I'm way ahead of you here. Take a look at page 7 of
ftp://sqlstandards.org/SC32/SQL_Registry/registry.pdf
In fact, look at almost all the pages and you'll find "Perl DBI"
has a range of values somewhere :-)
> 5. Will there be a convenient way to query sub-constants? For
> example, will one be able to only find a bitmask for
> SQL_OJ_CAPABILITIES as a whole and have to interpret that
> manually to find out if LEFT joins are supported? Or will one
> be able to directly get at the SQL_OJ_LEFT (the first bit of
> SQL_OJ_CAPABILITIES) setting by letting get_info() interpret
> the bitmask?
The get_info does exactly what ODBC's GetInfo does.
It's up to the caller to interpret the results.
Whatever solution is found for the name-to-number mapping
should probably also include the named constants for the
return values, including bit fields.
> 6. Is it possible to encourage DBD drivers to keep all of the
> get_info information in a maximally legible fashion? For
> example there could easily be a function (which I'd be glad
> to supply) which could recieve a string like the one below
> and return the bitmask 0x00000037:
>
> SQL_OJ_CAPABILITIES
> /*
> SQL_OJ_LEFT + left joins SUPPORTED
> SQL_OJ_RIGHT + right joins SUPPORTED
> SQL_OJ_FULL + full joins SUPPORTED
> SQL_OJ_NESTED - nested joins not supported
> SQL_OJ_NOT_ORDERED + on clause col order not required
> SQL_OJ_INNER + inner joins SUPPORTED
> SQL_OJ_ALL_COMPARISON_OPS - on clause comp op must be =
> */
That shouldn't be done in one/all drivers. That's the kind of thing
that could/should be in an external module.
> Enough for now.
:-)
Tim.
> --
> Jeff
