Elasticsearch version: master @ 65dbc17

The ODBC driver uses now the results return by SYS TYPES query to answer app's inquiries on column types. The following is a list of proposed changes that would be needed to stay inline with the ODBC spec:

• PRECISION and AUTO_INCREMENT columns:
  These have been renamed in ODBC 3.x to COLUMN_SIZE (just like already returned by SYS COLUMNS) and AUTO_UNIQUE_VALUE respectively. The plugin currently returns the JDBC nomenclature. Not positive what we should do here: in ODBC no application should ever look at the column names, because ODBC specifies what should be returned in each column by order, not name. If this is the case also for JDBC, I'd recommend renaming to the ODBC standard.
• DATE data type:
  • This type is currently assigned the value 93 in column DATA_TYPE. In both ODBC and JDBC specs, this value corresponds to a TIMESTAMP type (SQL_TYPE_TIMESTAMP). Moreover, ES/SQL does return a timestamp representation of it (ISO8601). So I'm not sure what we want to have here, but I believe we should either correct the value to 91 (SQL_TYPE_DATE) or rename the type to 'TIMESTAMP'.
  • The value for column PRECISION(/COLUMN_SIZE) for this type should be 20 (not 19). This is because this indicates the “number of characters in the character representation” and len("1953-09-02T00:00:00Z")==20 (interestingly, SYS COLUMNS does return value 20 for COLUMN_SIZE column already). Note: this might need to be adjusted to 24, if SQL: inconsistent date(time) format handling. #30002 is implemented; alternatively, if we choose not to implement that, we need to make sure we always return the date/time representation without the milliseconds component.
• SQL_DATA_TYPE column:
  The values in this column are always 0. The JDBC doesn't make use of this column ("unused"). The ODBC spec mandates that “[t]his column is the same as the DATA_TYPE column, except for interval and datetime data types.”
  Now, we don't have interval types, so that's fine. For the DATE data type, this column should have the value 9 (ODBC's SQL_DATETIME value) and column SQL_DATETIME_SUB should have either value 3 (ODBC's SQL_CODE_TIMESTAMP value) or 1 (ODBC's SQL_CODE_DATE value), according to the decision for the point above. Codes are concisely explained here and the values lifted from the specs.
• SQL_DATETIME_SUB column:
  This is currently null. The JDBC doesn't make use of the column ("unused"). For ODBC, it should be 0 for all types, except for DATE/TIMESTAMP where it should 3 or 1 (as per above).
• AUTO_INCREMENT(/AUTO_UNIQUE_VALUE) column:
  The column is currently always null. However, SYS COLUMNS returns NO in the equivalent IS_AUTOINCREMENT column, instead of a corresponding empty string for the unknown/not_applicable case (as null indicates). I believe we should synchronise these two columns to return either null/"" or preferably false/NO.
• MINIMUM_SCALE and MAXIMUM_SCALE columns:
  The values here are always null, while they should be 0 for the exact numeric types (the ints); also if DATE is transitioned fully to TIMESTAMP, it's corresponding values should be 0 or 3, depending on how SQL: inconsistent date(time) format handling. #30002 is implemented.
• PRECISION column:
  For numeric types, this column should contain “the maximum number of digits used by the data type”. The values currently returned match the ODBC spec for all the integral types and for the FLOAT data type (7). For DOUBLE, it is 1 higher (16 returned vs 15 in the spec) and HALF_ and SCALED_FLOAT have no direct equivalent since their data type (6) is reserved for variable precision floats. So I just wanted to make sure that the non-aligned values are accurate (which is possible).