Re: Better support for DBI::Const::GetInfo::ODBC's use in drivers

[Sorry for the late reply]

I'd rather DBI::Const::GetInfoReturn and DBI::Const::GetInfoType
were extended and documented to provide whatever API you need.

Tim.


On Mon, Jun 11, 2012 at 09:00:06AM -0400, Brendan Byrd wrote:
> 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 <[email protected]>
> Brendan Byrd <[email protected]>
>