RESET SESSION v3

From: "Marko Kreen" <markokr(at)gmail(dot)com>
To: "Neil Conway" <neilc(at)samurai(dot)com>
Cc: PGSQL-Patches <pgsql-patches(at)postgresql(dot)org>
Subject: RESET SESSION v3
Date: 2007-04-08 08:08:35
Message-ID: e51f66da0704080108y19541backfbfb44e2e49913dd@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Changes in v3:

* DEALLOCATE PREPARE ALL
* RESET PLANS wont check for ACL_CREATE_TEMP anymore.
* Add prepare.h and portal.h to guc.c.

On 4/7/07, Neil Conway <neilc(at)samurai(dot)com> wrote:
> > * RESET SESSION does not ABORT anymore, instead fails if in transaction.

> I think it's quite bizarre to have RESET SESSION fail if used in a
> transaction, but to allow an equivalent sequence of commands to be
> executed by hand inside a transaction.

I think implicit ABORT would annoy various tools that
partially parse user sql and expect to know what transaction
state currently is. For them a new tranaction control statement
would be nuisance.

> guc.c is missing some #includes.

For some reason gcc4.0 did not show any warnings by default.

> > * DEALLOCATE PREPARE ALL gives bison conflicts. Is that even needed?
>
> Seems best to have it, for the sake of consistency. The shift/reduce
> conflict is easy to workaround, provided you're content to duplicate the
> body of the DEALLOCATE ALL rule -- e.g. see the attached incremental
> diff.

Thanks, included.

> > * Are the CommandComplete changes needed?
>
> Seems warranted to me. BTW, why is CLOSE's command tag "CLOSE CURSOR",
> not "CLOSE"? That seems needlessly verbose, and inconsistent with other
> commands (e.g. DEALLOCATE).

Because the regular tag is "CLOSE CURSOR". I did not
want to break any expectations. But yes, the inconsistency
is weird.

> > * ResetPlanCache() is implemented as PlanCacheCallback((Datum)0,
> > InvalidOid); That seems to leave plans for utility commands untouched.
> > Is it problem?
>
> Yes, I'd think you'd also want to cleanup plans for utility commands.

Tom thought otherwise, so I kept the old way.

--
marko

Attachment Content-Type Size
reset_session_v3.diff application/octet-stream 28.0 KB

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Simon Riggs 2007-04-08 08:24:13 Re: LIMIT/SORT optimization
Previous Message Bruce Momjian 2007-04-08 02:16:34 Re: LIMIT/SORT optimization