New commands:

CLOSE ALL                      -- close all cursors
DEALLOCATE ALL                 -- close all prepared stmts
RESET PLANS                    -- drop all plans
RESET TEMP | TEMPORARY         -- drop all temp tables

RESET SESSION                  -- drop/close/free everything

So in the end RESET SESSION is eqivalent to following commands:

SET SESSION AUTHORIZATION DEFAULT;
RESET ALL;
DEALLOCATE ALL;
CLOSE ALL;
UNLISTEN *;
RESET PLANS;
RESET TEMP;

Changes in v2:

* RESET TEMPS -> RESET TEMP | TEMPORARY
* RESET SESSION does not ABORT anymore, instead fails if in transaction.
* DEALLOCATE ALL, CLOSE ALL and RESET SESSION change CommandComplete string
to "DEALLOCATE ALL", "CLOSE CURSOR ALL" and "RESET SESSION" respectively.
* Regression tests.
* Some docs.
* The ParamStatuses for changed options are already sent by ResetAllOptions(),
so this already works.

Questions:

* DEALLOCATE PREPARE ALL gives bison conflicts.  Is that even needed?

* Are the CommandComplete changes needed?  As there is possible to
hide DEALLOCATE ALL inside function?  OTOH, I like the idea
of more descriptive CommandComplete string.  I'd like it to
include even actual item name for ordinary DECLARE/CLOSE,
PREPARE/DEALLOCATE and SET/RESET in the future.

* ResetPlanCache() is implemented as PlanCacheCallback((Datum)0, InvalidOid);
That seems to leave plans for utility commands untouched.  Is it problem?
Should it walk plan list itself?


--
marko

Attachment: reset_session_v2.diff
Description: Binary data

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Reply via email to