You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ODBC specifies the order in which to return the supported data source types back to the application: the sort order [...] can be generalized as DATA_TYPE first, followed by TYPE_NAME, both ascending.
For the current data types returned, ordering by DATA_TYPE will be sufficient (the result is then also second degree ordered by TYPE_NAME).
FYI, the reason for ordering being that [m]ore than one SQL data type can map to a single type identifier, which can make it difficult (for the application) to determine which data type to use., so the ordering is supposed to also be done by how closely the data type maps to the corresponding ODBC SQL data type. This second criteria isn't necessarily applicable to our current set though (the example given is the definition of two integral types, one auto-incrementable, which would need to be ordered as second, since auto-incrementing property is not specific to an ODBC integral type).
The text was updated successfully, but these errors were encountered:
Tweak the return data, in particular with regards for ODBC columns to
better align with the spec
Fix order for SYS TYPES and TABLES according to the JDBC/ODBC spec
Fix#30386Fix#30521
Elasticsearch version: master @ 65dbc17
ODBC specifies the order in which to return the supported data source types back to the application:
the sort order [...] can be generalized as DATA_TYPE first, followed by TYPE_NAME, both ascending
.For the current data types returned, ordering by
DATA_TYPE
will be sufficient (the result is then also second degree ordered byTYPE_NAME
).FYI, the reason for ordering being that
[m]ore than one SQL data type can map to a single type identifier, which can make it difficult
(for the application)to determine which data type to use.
, so the ordering is supposed to also be doneby how closely the data type maps to the corresponding ODBC SQL data type
. This second criteria isn't necessarily applicable to our current set though (the example given is the definition of two integral types, one auto-incrementable, which would need to be ordered as second, since auto-incrementing property is not specific to an ODBC integral type).The text was updated successfully, but these errors were encountered: