RESET SESSION v2

From: "Marko Kreen" <markokr(at)gmail(dot)com>
To: PGSQL-Patches <pgsql-patches(at)postgresql(dot)org>
Subject: RESET SESSION v2
Date: 2007-04-03 07:15:58
Message-ID: e51f66da0704030015k74daf290ub068831b8b49bac3@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 Content-Type Size
reset_session_v2.diff application/octet-stream 27.3 KB

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Simon Riggs 2007-04-03 07:54:01 Re: scan_recycle_buffers
Previous Message Tom Lane 2007-04-03 06:30:07 Re: [HACKERS] Arrays of Complex Types