kylepbit commented on a change in pull request #9368: URL: https://github.com/apache/arrow/pull/9368#discussion_r652299841
########## File path: format/FlightSQL.proto ########## @@ -0,0 +1,337 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * <p> + * http://www.apache.org/licenses/LICENSE-2.0 + * <p> + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ + +syntax = "proto3"; + +option java_package = "org.apache.arrow.flight.sql.impl"; +package arrow.flight.protocol.sql; + +/* + * Wrapper for the result of a "GetSQLInfo" action. + */ +message ActionGetSQLInfoResult { + /* + * Values are modelled after ODBC's SQLGetInfo() function. This information is intended to provide + * Flight SQL clients with basic, SQL syntax and SQL functions related information. + * More information types can be added in future releases. + * E.g. more SQL syntax support types, scalar functions support, type conversion support etc. + * + * Initially, Flight SQL will support the following information types: + * - Server Information + * - + * + * 1. Server Information: Provides basic information about the Flight SQL Server. + * + * The name of the Flight SQL Server. + * FLIGHT_SQL_SERVER_NAME Review comment: I think using pseudo tables is an interesting concept, with some interesting pros/cons worth discussing to decide on an approach. Using pseudo tables allows for: - a simple proto definition - more expressiveness in terms of what can be done with the table, since it is then available for general SQL - allowing later additions without needing to modify any proto Drawbacks are mostly around two cases: those where metadata is not retrieved via a query mechanism and/or where it's more efficient not to use a query mechanism, and where you need to layer an additional parser in front of the actual database parser to support the pseudo. If we add a partial parser implementation to make it easier, we are having to implement this in all the languages that Flight SQL supports. If we use the existing proposed proto definitions, then I see the following: - less expressive in terms of what can be done - less flexibility in terms of adding new metadata calls - much less effort in that we don't need to provide a partial parser implementation to help - It's easy to go from a message to a SQL query if that's what's used for metadata, it's hard to go the other way around I think it would be easier all around to use what's defined here (with tweaks) vs. going the SQL table route, even though the SQL table route is more elegant from a protocol perspective. The effort to provide the hand-up for those data sources which don't have any support for querying metadata would be large, and may be a hinderance to adoption. -- 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
