Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e9fZq-0005Qi-RB for pgsql-hackers@arkaria.postgresql.org; Tue, 31 Oct 2017 23:04:10 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1e9fZq-0005Tj-AP for pgsql-hackers@arkaria.postgresql.org; Tue, 31 Oct 2017 23:04:10 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1e9fYH-0002hp-2I for pgsql-hackers@postgresql.org; Tue, 31 Oct 2017 23:02:33 +0000 Received: from mimolette.dalibo.net ([212.85.157.144] helo=mail.dalibo.com) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1e9fYD-0007sm-N9 for pgsql-hackers@postgresql.org; Tue, 31 Oct 2017 23:02:31 +0000 Received: from [192.168.1.100] (unknown [176.167.237.180]) by mail.dalibo.com (Postfix) with ESMTPSA id 471642C077D for ; Wed, 1 Nov 2017 00:02:27 +0100 (CET) Subject: Re: proposal: schema variables To: pgsql-hackers@postgresql.org References: <20171026220732.GI4496@localhost> <1509399760322-0.post@n3.nabble.com> <5665be80-1772-4998-8dbc-3bd071c0d9ad@rielau.com> <1509485317393-0.post@n3.nabble.com> <9f1f9d20-e913-82fb-c654-ae8c07537fee@dalibo.com> From: Gilles Darold X-Enigmail-Draft-Status: N1110 Message-ID: Date: Wed, 1 Nov 2017 00:02:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <9f1f9d20-e913-82fb-c654-ae8c07537fee@dalibo.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Le 31/10/2017 à 23:36, Gilles Darold a écrit : > Le 31/10/2017 à 22:28, srielau a écrit : >> Pavel, >> >> There is no >> DECLARE TEMP CURSOR >> or >> DECLARE TEMP variable in PLpgSQL >> and >> CREATE TEMP TABLE has a different meaning from what I understand you >> envision for variables. >> >> But maybe I'm mistaken. Your original post did not describe the entire >> syntax: >> CREATE [TEMP] VARIABLE [IF NOT EXISTS] name AS type >> [ DEFAULT expression ] [[NOT] NULL] >> [ ON TRANSACTION END { RESET | DROP } ] >> [ { VOLATILE | STABLE } ]; >> >> Especially the TEMP is not spelled out and how its presence affects or >> doesn't ON TRANSACTION END. >> So may be if you elaborate I understand where you are coming from. > I think that the TEMP keyword can be removed. If I understand well the > default scope for variable is the session, every transaction in a > session will see the same value. For the transaction level, probably the > reason of the TEMP keyword, I think the [ ON TRANSACTION END { RESET | > DROP } ] will allow to restrict the scope to this transaction level > without needing the TEMP keyword. When a variable is created in a > transaction, it is temporary if "ON TRANSACTION END DROP" is used > otherwise it will persist after the transaction end. I guess that this > is the same as using TEMP keyword? I forgot to say that in the last case the DECLARE statement can be used so I don't see the reason of this kind of "temporary" variables. Maybe the variable object like used in DB2 and defined in document : https://www.ibm.com/support/knowledgecenter/en/SSEPEK_11.0.0/sqlref/src/tpc/db2z_sql_createvariable.html could be enough to cover our needs. -- Gilles Darold Consultant PostgreSQL http://dalibo.com - http://dalibo.org -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers