Currently, the following language appears in DBI::Const::GetInfo::ODBC:
The API for this module is private and subject to change.
But, it really hasn't in 10 years, and it's quite handy for drivers to
use. Can we remove this warning and possibly document the module?
Here's an example of how DBD::SNMP is using it:
##############################################################################
# DBD::SNMP::GetInfo
package # hide from PAUSE
DBD::SNMP::GetInfo;
use sanity;
use parent qw(SQL::Statement::GetInfo);
sub sql_keywords {
return join(',', keys %{
SQL::Dialects::SNMP::get_config_as_hash()->{reserved_words} });
}
# GetInfo key adjustments
use DBI::Const::GetInfo::ODBC; # The API for this module is private
and subject to change.
# (Yes, I know, but it hasn't, and it's really handy...)
# More details on these variables here:
# http://msdn.microsoft.com/en-us/library/ms711681.aspx
# http://vieka.com/esqldoc/esqlref/htm/odbcsqlgetinfo.htm
my %r = %DBI::Const::GetInfo::ODBC::ReturnValues;
my %i = %DBI::Const::GetInfo::ODBC::InfoTypes;
our %info;
*info = *SQL::Statement::GetInfo::info;
# FIXME: This should actually be in SQL::Statement::GetInfo
$info{ $i{SQL_CREATE_TABLE} } = $r{SQL_CT_CREATE_TABLE} +
$r{SQL_CT_COMMIT_DELETE} + $r{SQL_CT_LOCAL_TEMPORARY};
$info{ $i{SQL_COLUMN_ALIAS} } = 'Y';
$info{ $i{SQL_SQL92_DATETIME_FUNCTIONS} } = $r{SQL_SDF_CURRENT_DATE} +
$r{SQL_SDF_CURRENT_TIME} + $r{SQL_SDF_CURRENT_TIMESTAMP};
$info{ $i{SQL_NUMERIC_FUNCTIONS} } = 0x00ffffff; # all of them!
$info{ $i{SQL_SQL92_NUMERIC_VALUE_FUNCTIONS} } =
$r{SQL_SNVF_BIT_LENGTH} + $r{SQL_SNVF_CHAR_LENGTH} +
$r{SQL_SNVF_CHARACTER_LENGTH} + $r{SQL_SNVF_OCTET_LENGTH} +
$r{SQL_SNVF_POSITION}; # (only missing EXTRACT)
$info{ $i{SQL_SQL92_STRING_FUNCTIONS} } = 0x000000fe; # (now with
TRANSLATE support; only missing CONVERT here)
$info{ $i{SQL_STRING_FUNCTIONS} } = 0x00ff7fff; # (only
missing DIFFERENCE)
$info{ $i{SQL_SYSTEM_FUNCTIONS} } = $r{SQL_FN_SYS_DBNAME} +
$r{SQL_FN_SYS_IFNULL} + $r{SQL_FN_SYS_USERNAME};
$info{ $i{SQL_ASYNC_MODE} } = $r{SQL_AM_CONNECTION}; #
though, technically, everything is forced as async
$info{ $i{SQL_DATA_SOURCE_READ_ONLY} } = 'Y'; # for the time being,
will change later
$info{ $i{SQL_FILE_USAGE} } = $r{SQL_FILE_NOT_SUPPORTED};
$info{ $i{SQL_MULTIPLE_ACTIVE_TXN} } = 'Y';
# RFC2578: OCTET STRING (SIZE (0..65535))
$info{ $i{SQL_MAX_BINARY_LITERAL_LEN} } = 65536;
$info{ $i{SQL_MAX_CHAR_LITERAL_LEN} } = 65536;
#$info{ $i{SQL_MAX_SCHEMA_NAME_LEN} } = ???; # Don't think there's
a max MIB name length...
$info{ $i{SQL_MAX_TABLE_NAME_LEN} } = 768; # XXX: This needs RFC
confirmation
$info{ $i{SQL_MAX_COLUMN_NAME_LEN} } = 768; # XXX: This needs RFC
confirmation
# RFC2574: msgUserName OCTET STRING (SIZE(0..32)),
$info{ $i{SQL_MAX_USER_NAME_LEN} } = 32;
# RFC1905: SNMPv2 limits OBJECT IDENTIFIER values to a maximum of 128
sub-identifiers, where each sub-identifier has a
# maximum value of 2**32-1.
$info{ $i{SQL_MAX_COLUMNS_IN_INDEX} } = 128;
$info{ $i{SQL_MAX_INDEX_SIZE} } = 128 * 10;
$info{ $i{SQL_SCHEMA_TERM} } = 'MIB';
$info{ $i{SQL_SCHEMA_USAGE} } = $r{SQL_SU_DML_STATEMENTS} +
$r{SQL_SU_TABLE_DEFINITION};
# We need to save some sanity here, so case sensitivity is OFF
$info{ $i{SQL_IDENTIFIER_CASE} } = $r{SQL_IC_MIXED};
--
Brendan Byrd <p...@resonatorsoft.org>
Brendan Byrd <bb...@cpan.org>
