From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Cc: | Kirk Wolak <wolakk(at)gmail(dot)com>, Gilles Darold <gilles(dot)darold(at)dalibo(dot)com> |
Subject: | proposal: plpgsql - OPEN LOCAL statement |
Date: | 2023-12-04 06:41:58 |
Message-ID: | CAFj8pRAVKhRiyQKDxhDFvWuixyf7-0o+aSKR99kqgpffqfc-pQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi
The lifecycle of cursors in plpgsql is not strictly joined with the life
cycle of related cursor's variables. Without breaking compatibility it is
not possible to change this behaviour. Usually it doesn't cause problems,
but in some cases very big numbers or unclosed cursors can force memory
issues that are not simple to investigate and are not too simple (in a
bigger project) to fix.
I think we can reduce this issue by enhancing the syntax of the OPEN
statement. New syntax can looks like
Current syntax (still will be supported)
OPEN cursorvar ...
New syntax
OPEN LOCAL cursorvar ...
With the clause LOCAL the opened cursor (and related portal) will be surely
closed immediately after function exit.
Probably we can enhance the syntax of DECLARE section too, so should be
possible to write
DECLARE cursorvar LOCAL CURSOR ...
What do you think about this proposal?
Regards
Pavel
From | Date | Subject | |
---|---|---|---|
Next Message | jian he | 2023-12-04 06:46:44 | Re: [PATCH] ltree hash functions |
Previous Message | zhihuifan1213 | 2023-12-04 06:37:02 | Avoid detoast overhead when possible |