pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedVisibility of a local variable
4+ messages / 3 participants
[nested] [flat]
* Visibility of a local variable
@ 2024-06-03 18:11 Alejandro Burne <adburne@gmail.com>
0 siblings, 1 reply; 4+ messages in thread
From: Alejandro Burne @ 2024-06-03 18:11 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org
A local variable, created within a transaction, continues to persist
(without value) after the transaction has ended.
> select version();
PostgreSQL 12.15 (Ubuntu 12.15-1.pgdg18.04+1) on x86_64-pc-linux-gnu,
compiled by gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0, 64-bit
> select current_setting('my.var1');
ERROR: parámetro de configuración «my.var1» no reconocido SQL state: 42704
(as expected)
> begin;
> set local my.var1 = true;
> commit;
(everything ok)
> select current_setting('my.var1');
returns an empty field (current_setting)
It should return the same error as in the first statement
Greetings, Alejandro
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Visibility of a local variable
@ 2024-06-04 16:01 David G. Johnston <david.g.johnston@gmail.com>
parent: Alejandro Burne <adburne@gmail.com>
0 siblings, 1 reply; 4+ messages in thread
From: David G. Johnston @ 2024-06-04 16:01 UTC (permalink / raw)
To: Alejandro Burne <adburne@gmail.com>; +Cc: pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
On Monday, June 3, 2024, Alejandro Burne <adburne@gmail.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.
Once a session knows a variable exists it cannot be made to not exist.
Only set back to its default empty string value (since custom variables are
only of type text)
David J.
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Visibility of a local variable
@ 2024-06-04 17:05 Tom Lane <tgl@sss.pgh.pa.us>
parent: David G. Johnston <david.g.johnston@gmail.com>
0 siblings, 1 reply; 4+ messages in thread
From: Tom Lane @ 2024-06-04 17:05 UTC (permalink / raw)
To: David G. Johnston <david.g.johnston@gmail.com>; +Cc: Alejandro Burne <adburne@gmail.com>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Monday, June 3, 2024, Alejandro Burne <adburne@gmail.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.
regards, tom lane
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Visibility of a local variable
@ 2024-06-04 19:55 David G. Johnston <david.g.johnston@gmail.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 4+ messages in thread
From: David G. Johnston @ 2024-06-04 19:55 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Alejandro Burne <adburne@gmail.com>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
On Tue, Jun 4, 2024 at 10:05 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "David G. Johnston" <david.g.johnston@gmail.com> writes:
> > On Monday, June 3, 2024, Alejandro Burne <adburne@gmail.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.
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2024-06-04 19:55 UTC | newest]
Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-06-03 18:11 Visibility of a local variable Alejandro Burne <adburne@gmail.com>
2024-06-04 16:01 ` David G. Johnston <david.g.johnston@gmail.com>
2024-06-04 17:05 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-06-04 19:55 ` David G. Johnston <david.g.johnston@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox