RESET SESSION v2 - Mailing list pgsql-patches

From Marko Kreen
Subject RESET SESSION v2
Date
Msg-id e51f66da0704030015k74daf290ub068831b8b49bac3@mail.gmail.com
Whole thread Raw
Responses Re: RESET SESSION v2
Re: RESET SESSION v2
List pgsql-patches
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

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Arrays of Complex Types
Next
From: "Simon Riggs"
Date:
Subject: Re: scan_recycle_buffers