jcralmeida commented on a change in pull request #11982:
URL: https://github.com/apache/arrow/pull/11982#discussion_r823791455
##########
File path: format/FlightSql.proto
##########
@@ -867,6 +867,167 @@ enum SqlSupportsConvert {
SQL_CONVERT_VARCHAR = 19;
}
+enum SqlDataType {
+ SQL_TYPE_UNKNOWN_TYPE = 0;
+ SQL_TYPE_CHAR = 1;
+ SQL_TYPE_NUMERIC = 2;
+ SQL_TYPE_DECIMAL = 3;
+ SQL_TYPE_INTEGER = 4;
+ SQL_TYPE_SMALLINT = 5;
+ SQL_TYPE_FLOAT = 6;
+ SQL_TYPE_REAL = 7;
+ SQL_TYPE_DOUBLE = 8;
+ SQL_TYPE_DATETIME = 9;
+ SQL_TYPE_INTERVAL = 10;
+ SQL_TYPE_VARCHAR = 12;
+}
+
+enum SqlDatetimeSubcode {
+ option allow_alias = true;
Review comment:
> As I understand it, the Flight SQL spec is not user-facing but
intended for implementors of bridges/drivers/adapters. So having convenience
aliases for the same numeric values doesn't seem very useful?
> (unless it can simplify the implementation of such
bridges/drivers/adaptaters?)
It facilitates the implementation because the values are identical to the
JDBC/ODBC
> I'm not sure this is resolved - if JDBC/ODBC use the same value for
different concepts, shouldn't we have separate values for them? For instance,
if a Flight SQL server wants to return XDBC_SUBCODE_DATE, how is it supposed to
know whether the client will interpret it as DATE or YEAR?
>
> If they are just different names for the same concept, we should pick just
one name and perhaps document the correspondence.
The XdbcDatetimeSubcode cannot be evaluated by itself. It should always be
related to the XdbcDataType.
For example, if it the XdbcDataType is Interval (10) the values 1 from the
XdbcDatetimeSubcode should be interpreted as YEAR. In case of Datetime (9) it
should be interpreted as Date
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
