alamb commented on issue #37720: URL: https://github.com/apache/arrow/issues/37720#issuecomment-1719837788
> I agree that this seems to be fairly low overhead, provided that the parameters are few and small in number (which isn't always the case, such as a parameterized INSERT statement etc.) I guess my only real concern is that we end up losing a lot of performance or will require externally preserved state to manage that handle (of course these are orthogonal to FlightSQL as it would be application defined). I wouldn't want the protocol to encourage having to embed the parameters directly in the client-side handle, but I also don't see a better solution to this offhand. I agree that the protocol should not require having the parameters in the handle and should not require a new handle to be sent in the response to `CommandPrepareStatementQuery` . However, allowing for a new handle for makes stateless services possible, which I think adds significant value to FlightSQL In terms of the performance penalty of passing parameter values back and forth, as you say that likely be application defined. For example, many systems have special (non SQL) ingest bulk ingest APIs that can avoid `INSERT` entirely (e.g. the Postgres `COPY` command is one example of such an API) -- 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
