Re: Visibility of a local variable

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alejandro Burne <adburne(at)gmail(dot)com>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: Visibility of a local variable
Date: 2024-06-04 19:55:29
Message-ID: CAKFQuwamy3VGC29STPvAJu0c9mMtOEknZX6FaWaw2idYGb5JPw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Tue, Jun 4, 2024 at 10:05 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> "David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> > On Monday, June 3, 2024, Alejandro Burne <adburne(at)gmail(dot)com> wrote:
> >> A local variable, created within a transaction, continues to persist
> >> (without value) after the transaction has ended.
>
> > This is under-documented but at present there is no plan to change this
> > long-standing behavior, just document it better.
>
> Keep in mind that this entire behavior (ie the ability to create GUCs
> not declared in the C code) is an undocumented abuse of the GUC
> system. We probably can't get rid of it at this late date, but
> we're very unlikely to make any incompatible changes in the behavior.
>
>
No, but this is another indication that there is demand for Pavel's schema
variables feature that it would be nice to point to instead of saying this
usable behavior is unsupported and has no supported alternatives.

David J.

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Casey & Gina 2024-06-04 20:00:44 Arrays are sorted when using intarray subtraction operator
Previous Message Tom Lane 2024-06-04 17:29:25 Re: BUG #18463: Possible bug in stored procedures with polymorphic OUT parameters