Hi Igniters,
Pavel,
A stateful SQL session enables SQL features whose state is modified by one
statement and consumed by subsequent statements.
One concrete use case is session-private temporary data, particularly ON COMMIT
PRESERVE ROWS semantics,
which cannot be implemented using stateless application attributes alone.
Maksim,
Thanks for the detailed explanation and the IEP-129 reference.
I agree that IEP-129 already solves propagation of application context by value
and that this model intentionally avoids server-side session state.
The concrete user-facing use case I have in mind is SQL temporary tables.
ISO SQL defines an SQL session context, and temporary-table instances are
associated with that context.
For example:
CREATE GLOBAL TEMPORARY TABLE tmp (...)
ON COMMIT PRESERVE ROWS;
Data inserted into this table must remain private to the session and be
available to subsequent statements and transactions until the session ends.
This cannot be implemented using stateless application attributes alone:
propagating a session ID is possible,
but the table data and its lifecycle still require server-side state associated
with that ID.
The propagation mechanism introduced by IEP-129 could certainly be reused.
However, I am not sure that a stateful session should be treated simply as an
extension of that IEP.
IEP-129 is focused on attributes and operation-context propagation, while a
stateful session introduces a different set of concerns:
trusted identity, ownership, mutable state, lifecycle, cleanup, reconnect,
failover, and security.
Therefore, it may be clearer to discuss stateful SQL sessions in a separate
proposal that builds on IEP-129 where appropriate.
