Re: DISCARD ALL (Again)
От | Robert Haas |
---|---|
Тема | Re: DISCARD ALL (Again) |
Дата | |
Msg-id | CA+TgmoYfVh44VP=Ots1qyHVpcsjL1u_jZKTeBzryXYdkCfPTJw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: DISCARD ALL (Again) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: DISCARD ALL (Again)
|
Список | pgsql-hackers |
On Fri, Apr 18, 2014 at 2:24 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > 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? This is not the first time that somebody's asked for a way to throw away global interpreter state, and I really think we ought to oblige. In a connection-pooling environment, you really need a way to get the connection back to its original state rather than some not-so-near facsimile thereof. Maybe it'll end up as an optional behavior, and which kind of reset to use will become part of the pooler configuration, but that doesn't bother me as much as not having it for those that want it. What's a bit odd about this request is that it asks for the ability to throw away only part of the state. ISTM that if somebody wants to add that kind of capability, they ought to just package a function which does precisely that with the plpython extension, or create a Python function that zaps that particular variable if that's possible. I think it's clearly useful to have DISCARD ALL be a request to discard *everything* in one shot, but it's going to be a stretch to come up with DISCARD variants for every kind of partial state removal somebody wants to do. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: