"Joshua D. Drake" <jd@commandprompt.com> writes:
> Does it seem reasonable based on the docs:
> DISCARD ALL:
> Releases all temporary resources associated with the current session and
> resets the session to its initial state.
> That we should also release the GD?
There are a couple of reasons why this isn't anywhere near as
open-and-shut as you seem to think:
1. The things that DISCARD ALL resets are explicitly enumerated in its
documentation page; it is not an open-ended promise to clean up anything
anybody happens to think of. In particular, I would object to adding any
such functionality that doesn't correspond to a more specific form of
DISCARD, RESET, or whatever.
2. While I'm no Python expert, I believe GD is just a specific instance
of a general capability for global state in Python. Are we going to
promise that any and all user-created data inside Python goes away?
What about other PLs? Will users thank us if this suddenly starts
happening?
3. Since PL/Python is a superuser-only language, destroying either all
global state or just GD should require superuser privileges. It will
definitely break things to make DISCARD ALL require superuser privs.
It's not very much more attractive to say that it only destroys Python
state if issued by a superuser.
We could in fact implement #2, I imagine, by destroying and recreating
the entire language interpreter. So I could imagine implementing a
"DISCARD INTERPRETERS" kind of command that would zap the current
interpreter(s) for whichever PL languages happened to feel like
cooperating with the command. But I'm not at all sure about the
superuser-privileges aspect of that.
More: IIRC, in at least some of the PLs, the interpreters are
SQL-user-specific. Should a non-superuser session user have the ability
to destroy state in interpreters running for other user IDs (presumably,
state created by SECURITY DEFINER functions)? I'd guess not.
On the whole I'm not sure this is something we ought to get into.
If you really need a fresh session, maybe you should start a
fresh session. But if we are going to get into it, I think the
permissions aspect needs some careful thought.
regards, tom lane