Closed jduo closed 6 years ago
Agreed. Probably makes sense (in some scenarios) for the second parameter to be a driver-type, as returned in SQLGetTypeInfo or SQLStructuredTypes.
Do we need different versions, one for driver types and one for sql types?
Note that the driver already returns what sql type conversions it supports...
Proposal: Keep SAFECONVERT for using SQL_TYPES (not including SQL_UDT, SQL_ROW, SQL_MULTISET, or SQL_ARRAY); this is simplest for common built-in types. Introduce a new canonical function ("TREAT"?) for treating a property as a particular structured type (perhaps also support native types), as well as TYPEOF for getting the type of an (i.e., variant) column (see issue #50).
Added a SAFECAST function which takes the type name:
The SAFECAST function, which can be invoked using the function escape clause, allows an expression to be treated as the specified user-defined or datasource-specific type.
SAFECAST ( value-exp, data-type-name )
The result of the SAFECAST function is the value of value-exp converted to data-type-name, where data-type-name is datasource-specific type, or the fully qualified name of a user defined or structural type. If the value of value-exp cannot be converted to data-type-name, the result is null.
The specification for SAFECONVERT() takes in a finite set of data types for its second parameter, similar to the CONVERT() scalar function. This limits its utility since you can't really specify the shape of structured types or use data-source-specific identifiers.