search

microsoft / ODBC-Specification

Microsoft ODBC Specification
Other
122 stars 40 forks source link

Array Element Reference disambiguation #58

Open matthew-wozniczka opened 7 years ago

matthew-wozniczka commented 7 years ago

Section 3.11.2.1 (Array Element Reference) states

Note that some data sources may use a bracketed string following a field name in the select list as a shortcut for aliasing the field. For fields representing arrays, if the bracketed value is a number the driver must ensure that it is used as an index, not as an alias.

Just to be clear, this only applies to column/field references which refer to a fixed, non-SQL_VARIANT column, correct?

matthew-wozniczka commented 7 years ago

Actually, thinking about it further, variant/dynamic columns/fields need to be casted to an array type before doing the array element reference(right?), so that should resolve that ambiguity (though it may still be hard to implement due to it affecting parsing).

mikepizzo commented 7 years ago

Yes; I would expect that an array/dynamic column would need to be cast to an array type before doing the element dereferencing. Is the issue for parsers that they may not understand how to interpret the brackets without knowing the type of the column (i.e., whether or not it is collection-valued)? From an ANSI standpoint, the brackets would always reference an element of the array, we're just trying to account for existing implementation syntax that use this as a shortcut for aliasing.

matthew-wozniczka commented 7 years ago

Yes, the parser (probably) won't know the type of the column, so it can't make a decision on how to interpret the brackets.

The only way it could comply with the spec (without a large change to the impl. to leave the disambiguation to a later stage of processing) is to assume it's always an array element reference, which would change the semantics of existing queries.