"Joshua D. Drake" <j...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers