Dear Tim,
Errrmmm...
Is NUM_PREC_RADIX at 15 or 18 or both? I think it should be at 18 only.
I note that the numbers in the type_info_all array/hash are off-by-one
compared with the SQLGetTypeInfo() method in ODBC, and SQL_DATA_TYPE
appears at 16 in the current version of the man page at MS web site,
so it should be at 15 in DBI; then SQL_DATETIME_SUB, NUM_PREC_RADIX and
INTERVAL_PRECISION (at 19 in MS/ODBC, 18 in DBI)?
Is that correct? If so, then we need to note that the DBI 1.32 spec which
places NUM_PREC_RADIX at 15 leaves us with a compatibility problem?
<grin>
Maybe we should have the zeroth column as the DBI version number, and then
have the other column numbers matching the ODBC spec?
</grin>
That seems more than a trifle wasteful, not to mention backwards
incompatible, so it is not a very serious suggestion.
--
Jonathan Leffler ([EMAIL PROTECTED])
STSM, Informix Database Engineering, IBM Data Management Solutions
4100 Bohannon Drive, Menlo Park, CA 94025
Tel: +1 650-926-6921 Tie-Line: 630-6921
"I don't suffer from insanity; I enjoy every minute of it!"
|---------+---------------------------->
| | Tim Bunce |
| | <Tim.Bunce@pobox.|
| | com> |
| | |
| | 12/16/2002 04:38 |
| | AM |
| | |
|---------+---------------------------->
>---------------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: Jonathan Leffler <[EMAIL PROTECTED]>
|
| cc: Tim Bunce <[EMAIL PROTECTED]>, DBI Developers Mailing List
<[EMAIL PROTECTED]>, Jonathan Leffler/Menlo Park/IBM@IBMUS |
| Subject: Re: Metadata methods in DBI
|
|
|
|
|
>---------------------------------------------------------------------------------------------------------------------------------------------|
On Mon, Dec 16, 2002 at 03:21:12AM -0800, Jonathan Leffler wrote:
>
> Yet another question -- given the specifications of type_info_all and
> type_info, how does type_info get hold of the SQL_DATA_TYPE,
> SQL_DATETIME_SUB and INTERVAL_PRECISION fields, given that they are
> not listed in the type_info_all structure?
Ah, [...rummages in ODBC 3.5 reference book...] Okay, I've just added these
extra items to the info to be returned by type_info_all:
SQL_DATA_TYPE => 16,
DATETIME_SUB => 17,
NUM_PREC_RADIX => 18,
INTERVAL_PRECISION=> 19,
I'd just left them out when I added the extra field descriptions
into the type_info docs. Note that DATETIME_SUB is misspelled with
an SQL_ prefix in the docs. That's wrong. Fixed now.
Driver authors please note!
> Also, the spiel for SQL_DATA_TYPE says:
>
> <quote>This column is the same as the DATA_TYPE column, except for
> interval or datetime types. For interval and datetime data types, the
> SQL_DATA_TYPE field will return SQL_INTERVAL or SQL_DATETIME, and the
> SQL_DATETIME_SUB field will return the subcode for the specific
> interval or datetime data type. If this field is NULL, then the
> driver does not support or report on interval or date types.</quote>
>
> Questions arising:
> 1. That last 'date' should be 'datetime' to be consistent.
Yeap. Fixed. Thanks.
> 2. What does the DATA_TYPE field contain when this field contains
> SQL_DATETIME or SQL_INTERVAL? Not that value - but which value?
The "consise" type integer, ie 112 for SQL_INTERVAL_HOUR_TO_SECOND.
So when SQL_DATA_TYPE = SQL_DATETIME or SQL_INTERVAL then
DATA_TYPE == DATETIME_SUB. (Yes, DATETIME_SUB does seem redundant
but that's what the ODBC spec calls for.)
> In the context of type_info_all, you say 'driver-specific columns of
> information ... start at column index 50 to leave room for expansion'.
> How do you write an initializer for the gap between the 14 (17?)
> defined attributes and the index where the driver-specific attributes
> can start? Or is that a subtle hint not to define driver-specific
> attributes? I'm looking at the code with lines like:
>
> [ 'INTEGER', SQL_INTEGER, undef, "", "", undef, ... ],
>
> With the first 14 columns defined, there has to be 36 empty columns
> left unefined, or zeroed, or something; is there a neat notation to do
> that? 36*undef or something useful?
..., (undef) x 36, ...
(The undef must be in parens to get the "x" operator to replicat the list.)
Tim.
