Re: DISCARD ALL does not force re-planning of plpgsql functions/procedures
| От | Jelte Fennema-Nio |
|---|---|
| Тема | Re: DISCARD ALL does not force re-planning of plpgsql functions/procedures |
| Дата | |
| Msg-id | CAGECzQROQcYhFfehunv25CWjFrNBzn9fXmbw3kDDbKVp3O6tXw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: DISCARD ALL does not force re-planning of plpgsql functions/procedures (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: DISCARD ALL does not force re-planning of plpgsql functions/procedures
Re: DISCARD ALL does not force re-planning of plpgsql functions/procedures |
| Список | pgsql-hackers |
On Sun, 26 May 2024 at 19:39, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Hm, should it be? That's hard-won knowledge, and I'm not sure there
> is a good reason to believe it's no longer applicable.
I think for DISCARD ALL it would probably make sense to forget this knowledge . Since that is advertised as "reset the session to its initial state". DISCARD PLANS should probably forget about it though indeed.
> Note that any change in behavior there would affect prepared
> statements in general, not only plpgsql.
> Hm, should it be? That's hard-won knowledge, and I'm not sure there
> is a good reason to believe it's no longer applicable.
I think for DISCARD ALL it would probably make sense to forget this knowledge . Since that is advertised as "reset the session to its initial state". DISCARD PLANS should probably forget about it though indeed.
> Note that any change in behavior there would affect prepared
> statements in general, not only plpgsql.
DISCARD ALL already removes all prepared statements and thus their run counts, so for prepared statements there would be no difference there.
В списке pgsql-hackers по дате отправления: