-
Notifications
You must be signed in to change notification settings - Fork 25.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ODBC: SYS COLUMNS column types alignment #35376
Labels
:Analytics/SQL
SQL querying
Comments
Pinging @elastic/es-search-aggs |
costin
added a commit
to costin/elasticsearch
that referenced
this issue
Nov 23, 2018
Due to some unresolvable type conflict between the expected definition in JDBC vs ODBC, the driver mode is now passed over so that certain command can change their results accordingly (in this case SYS COLUMNS) Fix elastic#35376
costin
added a commit
that referenced
this issue
Nov 26, 2018
Due to some unresolvable type conflict between the expected definition in JDBC vs ODBC, the driver mode is now passed over so that certain command can change their results accordingly (in this case SYS COLUMNS) Fix #35376
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
SYS COLUMNS
maps on the ODBC catalog functionSQLColumns()
. This function prepares a table for the application to subsequently fetch. The table definition is given within the spec.Current
SYS COLUMNS
implementation is aligned with the spec with the exception of the following columns, that are all returned asinteger
, while the application expects them as "Smallint" (i.e. SQLSHORT
):DATA_TYPE
,DECIMAL_DIGITS
,NUM_PREC_RADIX
,NULLABLE
,SQL_DATA_TYPE
,SQL_DATETIME_SUB
.This misalignment is problematic for the applications that:
For example: when fetching
DATA_TYPE
value, the application provides a two byte buffer (to accommodate theSHORT
). Leaving the conversion to "default", the driver would then try to access a four byte buffer, corresponding to DB'sINTEGER
, which eventually leads to a failure.Now, this application behavior is not really correct (and the spec advises against using "default" data type, but this is too late for 2.x applications). However, this problem can be mitigated if we aligned our types with the spec.
The text was updated successfully, but these errors were encountered: