Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h1o7C-0002Sr-4e for pgsql-hackers@arkaria.postgresql.org; Thu, 07 Mar 2019 08:10:54 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1h1o7A-0004q6-L7 for pgsql-hackers@arkaria.postgresql.org; Thu, 07 Mar 2019 08:10:52 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h1o7A-0004py-DQ for pgsql-hackers@lists.postgresql.org; Thu, 07 Mar 2019 08:10:52 +0000 Received: from courriel.mines-paristech.fr ([77.158.173.149] helo=antispam-1.ensmp.fr) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h1o77-00079F-U8 for pgsql-hackers@lists.postgresql.org; Thu, 07 Mar 2019 08:10:51 +0000 Received: from smtp-4.mines-paristech.fr (smtp-4.ensmp.fr [77.158.173.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by antispam-1.ensmp.fr (antispam.mines-paristech.fr) with ESMTPS id 25E0855E2C; Thu, 7 Mar 2019 09:10:48 +0100 (CET) Received: from lancre-wln.cri.ensmp.fr (sfr-14.cri.mines-paristech.fr [77.158.180.238]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp-4.mines-paristech.fr (Postfix) with ESMTPSA id D24FC2C0432; Thu, 7 Mar 2019 09:10:47 +0100 (CET) Date: Thu, 7 Mar 2019 09:10:47 +0100 (CET) From: Fabien COELHO X-X-Sender: fabien@lancre To: David Steele cc: Pavel Stehule , Artur Zakirov , Dean Rasheed , Gilles Darold , PostgreSQL Hackers , Peter Eisentraut Subject: Re: Re: [HACKERS] proposal: schema variables In-Reply-To: Message-ID: References: <20180919112305.GA18604@zakirov.localdomain> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-CLAMAV-SCAN: ok X-VRSPAM-SCORE: -100 X-VRSPAM-STATE: legit X-VRSPAM-CAUSE: gggruggvucftvghtrhhoucdtuddrgedutddrfeejgdduudekucetufdoteggodetrfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvufgjkfhffgggtgesthdtredttdervdenucfhrhhomhephfgrsghivghnucevqffgnffjqfcuoegtohgvlhhhohestghrihdrvghnshhmphdrfhhrqeenucfkphepjeejrdduheekrddukedtrddvfeeknecurfgrrhgrmhepmhhouggvpehsmhhtphhouhht X-VRSPAM-EXTCAUSE: mhhouggvpehsmhhtphhouhht List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hello David, > This patch hasn't receive any review in a while and I'm not sure if that's > because nobody is interested or the reviewers think it does not need any more > review. > > It seems to me that this patch as implemented does not quite satisfy any one. > > I think we need to hear something from the reviewers soon or I'll push this > patch to PG13 as Andres recommends [1]. I have discussed the feature extensively with Pavel on the initial thread. My strong opinion based on the underlying use case is that it that such session variables should be transactional by default, and Pavel strong opinion is that they should not, to be closer to Oracle comparable feature. According to the documentation, the current implementation does provide a transactional feature. However, it is not the default behavior, so I'm in disagreement on a key feature, although I do really appreciate that Pavel implemented the transactional behavior. Otherwise, ISTM that they could be named "SESSION VARIABLE" because the variable only exists in memory, in a session, and we could thing of adding other kind of variables later on. I do intend to review it in depth when it is transactional by default. Anyway, the patch is non trivial and very large, so targetting v12 now is indeed out of reach. -- Fabien.