proposal: plpgsql - OPEN LOCAL statement

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

Browse pgsql-hackers by date

  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