Direct control over committing (flushing) inserted rows

[tst60]

When using an upstream source that it isn't naturally ordered (e.g. certain unordered messaging technologies), the offsetToken doesn't provide a good mechanism for at-least-once delivery, as there is no existing ordered token to use, or method to replay data in order.

In such cases it would be useful to explicitly commit inserts, so that upstream messages can be safely acknowledged/deleted.

At the moment, one alternative may be to generate random/pseudo-random offsetTokens and poll the getLatestCommittedOffset, but this seems unnecessarily cumbersome - it would be simpler to allow the user of the client to take control over when to commit inserts in these cases, and expose the "flush/commit" directly as an accessible method.

[aronsemle]

+1 to this. This relates to my request #802. I want control over when the commit occurs. As is the sending thread has a 1 second max delay, which seems reasonable but when I'm sending a lot of data, 1 second adds up.

[sfc-gh-xhuang]

Snowpipe Streaming is async commit and there is no client interaction of a "commit".
The client can do an upload/flush which can be controlled through the max_client_lag property (minimum 1second max 10 minutes)
But Snowflake still has to "commit" that upload asynchronously into the table on the server side. It's not directly commited by the client side flush.