[FlightSQL] Support detached execution for long-running DDL/DML

[xborder]

Hi everyone,

Flight SQL defines CommandStatementUpdate and CommandPreparedStatementUpdate as DoPut operations. The server consumes the request, executes the statement, and returns a DoPutUpdateResult, usually containing the affected-row count.
This works for short-running statements, but I'm looking for an alternative to avoid having to keep long lived connections when running long DML/DDL operations.

PollFlightInfo appears relevant because it supports long-running Flight operations, but Flight SQL does not define how either update command maps to PollFlightInfo.
From my understanding, using a similar mechanism for DDL/DML queries is not supported by the protocol because:

1. DoPut(CommandStatementUpdate/CommandPreparedStatementUpdate) is what binds parameters
2. The update count comes as a result of DoPut (i.e PutResult(DoPutUpdateResult))

I did some research trying to understand if other platforms supported this:

• StarRocks: Does not seem to show PollFlightInfo support for updates
• ClickHouse: DDL/DML and prepared updates execute synchronously through DoPut
• GizmoSQL: Direct and prepared updates execute in DoPut after all parameters are consumed, with no PollFlightInfo implementation
• InfluxDB: InfluxDB 3 Core uses GetFlightInfo/DoGet and leaves PollFlightInfo unimplemented
• Apache Doris: Doris uses GetFlightInfo with FE/BE result retrieval, but current sources leave direct updates unimplemented, prepared updates incomplete, and provide no PollFlightInfo path

---

Is there a scenario where CommandStatementUpdate and CommandPreparedStatementUpdate can be used for long running queries that I'm missing?

[vynazevedo]

Long-running updates can use those commands, but the DoPut RPC stays open until the server returns the update result. The current Flight SQL specification doesn't give these commands a detached job handle that a client can poll later.

One detail in point 1: CommandStatementUpdate carries the SQL statement; it isn't a parameter-binding step. For prepared statements, the split between binding via DoPut and execution via GetFlightInfo belongs to CommandPreparedStatementQuery. DoPut(CommandPreparedStatementUpdate) executes the update and returns its count. See Query Execution.

PollFlightInfo works with a FlightInfo result and its endpoints. It doesn't define a way to retrieve a DoPutUpdateResult after the original update RPC has ended. Also, record_count = -1 means an unknown count, not a pending operation or a job identifier.

If you control both ends, a separate submit/status API with a durable job ID could provide that lifecycle, including the final count or error. That would be an extension rather than something ordinary Flight SQL clients can use automatically. I'd make retry/idempotency and transaction lifetime explicit there: reconnecting after a timeout mustn't accidentally execute the same update twice.