RESET SESSION v3
От | Marko Kreen |
---|---|
Тема | RESET SESSION v3 |
Дата | |
Msg-id | e51f66da0704080108y19541backfbfb44e2e49913dd@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: RESET SESSION v3
Re: RESET SESSION v3 |
Список | 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
Вложения
В списке pgsql-patches по дате отправления: