Closed mikepizzo closed 7 years ago
Leveraging SQL_DATA_TYPE seems preferable as it aligns with SQL_DATETIME usage, although following that pattern might require additional columns much like SQL_DATETIME_SUB. Perhaps SQL_DATETIME_SUB could then be overloaded to hold the additional information based on different values for SQL_DATA_TYPE.
We looked at overloading SQL_DATA_TYPE, but it only supports one level of additional information. Where we really needed this was array type, and it broke down as soon as we considered arrays of arrays. Instead, we defined a more extensible naming scheme for the column name that allows referencing members within the collection.
We don't other compelling scenarios for this, so closing the issue. If we have other scenarios we can open issues for those scenarios.
We can use descriptors to describe things like string format, array type, etc. in a result, but how do we describe that in the schema functions (i.e., SQLColumns)?
Could we overload TYPE_NAME or leverage difference between DATA_TYPE and SQL_DATA_TYPE?