api_stream.txt

We need chunked data stream in the SQL API. There are two approaches to it. First is to use push server API. Second is to extend current protocol. In both cases we need server transformation. Now all SQL result is send via one function without suspension. This should be changed. It's good to have for C API cancel or kill command for executed statement without closing connection. If I call statement_close() on client side server should stop sending data and back off. Although it's a right way to use push for streamed data seems it's much easy to implement protocol changes. Protocol changes can be implemented in stages; first is to adapt protocol and second make a real changes in Server for streamed  chunked data.

How to change protocol:
The idea is to allow to send SQL result packets many times and introduce end of data flag. This feature may be enabled in opt-in or opt-out ways. 
1) In opt-in approach client should send special option. We need to add a new SQL option in the IPROTO_SQL_OPTIONS (which is renamed to IPROTO_OPTIONS in a pending to review patch). A flag can be used like IPROTO_OPTION_CHUNKED to send a big response in several messages, or IPROTO_OPTION_CHUNK_TUPLES, that if specified allows to not only trigger data chunking, but also to specify a chunk size. 
2) in opt-out way client should always expect to read response many times until they see EOF flag. Server can add EOF even in first packet. Thus this approach is compatible with current protocol. 
Client should issue read reply in loop until it meet packet with EOF flag in IPROTO_METADATA. Then client should not issue new read if it met this flag set.
Also it will be good to introduce command "cancel" to allow client to interrupt long running SQL request thus freeing server resources such as memory, context, cursors, etc. It can be part of IPROTO_CTL for example. This feature seems to be useful not only for SQL, but for any long-polling request. For example, to cancel a function running on a server too long. I think, that it must not be only SQL feature. A client must be able to send a new message in the scope of already working request with the same sync.
Then the server push mechanism will be available this steaming mechanism should be adapted to it.