RESET SESSION v3 - Mailing list pgsql-patches

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

pgsql-patches by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: LIMIT/SORT optimization
Next
From: "Simon Riggs"
Date:
Subject: Re: LIMIT/SORT optimization