CurtHagenlocher commented on PR #2698: URL: https://github.com/apache/arrow-adbc/pull/2698#issuecomment-2809785069
I feel like I don't entirely understand this change, so it would be nice to get a little more explanation. Today, there's a limitation in ADBC which prevents a single execution batch from returning multiple results. Now obviously, multiple statements doesn't have to mean multiple results because a statement could be e.g. DDL or BEGIN TRAN or some other thing which impacts session state. But accepting multiple statements implies that they *could* each be returning results, and that's where things feel a little sketchy. It looks like the two added parameters are intended to filter down the set of results in order to pick just one. But they do so in a way that doesn't (to me) obviously ensure that only one result will match the criteria. What if there are two results with the same statement type and evaluation kind? Picking the first one feels a little arbitrary. What I'd naively expect if I passed multiple statements and needed to indicate which one's results I wanted would be to supply the index of the statement. So for "statement1; statement2; statement3", if I wanted the results from statement2 I might pass either 1 or 2 depending on how I feel about zero-indexing vs one-indexing. Is the current design something that users of the e.g. BigQuery ODBC driver would already be familiar with? Do certain statement types and evaluation kinds never come with real result data and can therefore be omitted by default if e.g. an index wasn't specified? -- 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: github-unsubscr...@arrow.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
