Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sEXbp-0021Yw-3K for pgsql-bugs@arkaria.postgresql.org; Tue, 04 Jun 2024 17:06:06 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sEXbo-0011sJ-L2 for pgsql-bugs@arkaria.postgresql.org; Tue, 04 Jun 2024 17:06:04 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sEXbo-0011sB-7E for pgsql-bugs@lists.postgresql.org; Tue, 04 Jun 2024 17:06:04 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sEXbl-003QlP-Cn for pgsql-bugs@lists.postgresql.org; Tue, 04 Jun 2024 17:06:02 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 454H5vJn479910; Tue, 4 Jun 2024 13:05:57 -0400 From: Tom Lane To: "David G. Johnston" cc: Alejandro Burne , "pgsql-bugs@lists.postgresql.org" Subject: Re: Visibility of a local variable In-reply-to: References: Comments: In-reply-to "David G. Johnston" message dated "Tue, 04 Jun 2024 09:01:56 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <479908.1717520757.1@sss.pgh.pa.us> Date: Tue, 04 Jun 2024 13:05:57 -0400 Message-ID: <479909.1717520757@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "David G. Johnston" writes: > On Monday, June 3, 2024, Alejandro Burne 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