Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e9kTw-0004Kn-Il for pgsql-hackers@arkaria.postgresql.org; Wed, 01 Nov 2017 04:18:24 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1e9kTv-0002nx-Tf for pgsql-hackers@arkaria.postgresql.org; Wed, 01 Nov 2017 04:18:23 +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_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1e9kSO-00004v-N0 for pgsql-hackers@postgresql.org; Wed, 01 Nov 2017 04:16:48 +0000 Received: from mail-wr0-x22b.google.com ([2a00:1450:400c:c0c::22b]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1e9kSG-0007me-Ct for pgsql-hackers@postgresql.org; Wed, 01 Nov 2017 04:16:47 +0000 Received: by mail-wr0-x22b.google.com with SMTP id o44so865987wrf.11 for ; Tue, 31 Oct 2017 21:16:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=g92A+ROSBFPceSdIIfWG3uLs/Ry/IFVF/qkGwgQ8sZk=; b=eN9s+oiMbK7CwMhwAZwPVujzWnC6glWq+17Xy+ZjtpPWhMUhjmTswT5uP9ksejCG0Y QG7yW6jQ8UfXbEXDABMYFx5bev17NY51fa6dixZUPsbhRmgTFE2B9M03xtTQkHtJoAJY I2ibELa+bXDWFQScPfpxp5wYfyUidc2HeMOgoFVK3okesFyuMdxI4y51W1Yw7eI3FFA1 GGAWX+J+uTeMnCQ+4ZmIcOvhJ0lhOOuivC4MHPMkLmbu/SFpTY5ubWMXA33sCEPaYO+K 09AbmMyt+QLIlSFLE/Le8ShKUngyiCrAwGkb7BjZkRiHoPz/8aw8EdCkY0lRzNJxBZ+T ALkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=g92A+ROSBFPceSdIIfWG3uLs/Ry/IFVF/qkGwgQ8sZk=; b=oQNQa8NQwEU2mXYXFmwOs3iPiexPAptVjmjjsZHR5BOmvBDc13Bd+aEzQXYtBGWOVh wwy0aG2hsw78KbeFTeMTpqBNANNBpeGTyySHgMYLC757ezkwQ0WzHNHmXKrpUMyhE0Iu YMAn2qn5OevhPj6+djqs7pi4itkRD8Iyfgc3UaE3XHdy/Q8ca4HDz+OcPA5HIMbfxndi /CK8/YyUgkEhjeXkaI5XxD8U1XpIk69ME6YWa5+/2wrzx7hHjYJkfeAZJIYDOmWUrUkr OMIv2q/AwtUfi38AKGA2aZV/IbLxmMswaKNL7EcRg2Ecbq716WzOfofvhi/cYz3VvdWR H0KQ== X-Gm-Message-State: AMCzsaVMkHUYXYU5ffiJ5ixP/SP31ctKlzaY33wPEdZdqiuiYLJKv0xw 3NwYVcSNsZ1oQcqS2gau+UIL3SxOZ8XvlQtQQAg= X-Google-Smtp-Source: ABhQp+Q4E5yKXwv6DnCfE5ds4vO92gquop/pvO9FJOM6PtxUo5cdEANNXhlM5bYtduNZjAu7lD6QoC0VoYRzFjUU22M= X-Received: by 10.223.170.67 with SMTP id q3mr3314164wrd.193.1509509798556; Tue, 31 Oct 2017 21:16:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.146.7 with HTTP; Tue, 31 Oct 2017 21:15:58 -0700 (PDT) In-Reply-To: <1509485317393-0.post@n3.nabble.com> References: <20171026220732.GI4496@localhost> <1509399760322-0.post@n3.nabble.com> <5665be80-1772-4998-8dbc-3bd071c0d9ad@rielau.com> <1509485317393-0.post@n3.nabble.com> From: Pavel Stehule Date: Wed, 1 Nov 2017 05:15:58 +0100 Message-ID: Subject: Re: proposal: schema variables To: srielau Cc: PostgreSQL Hackers Content-Type: multipart/alternative; boundary="94eb2c1cc5c853f931055ce42371" 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 --94eb2c1cc5c853f931055ce42371 Content-Type: text/plain; charset="UTF-8" 2017-10-31 22:28 GMT+01:00 srielau : > Pavel, > > There is no > DECLARE TEMP CURSOR > or > DECLARE TEMP variable in PLpgSQL > and > sure .. DECLARE TEMP has no sense, I talked about similarity DECLARE and CREATE TEMP 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. > TEMP has same functionality (and implementation) like our temp tables - so at session end the temp variables are destroyed, but it can be assigned to transaction. > > > > > -- > Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers- > f1928748.html > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > --94eb2c1cc5c853f931055ce42371 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


2017-10-31 22:28 GMT+01:00 srielau <serge@rielau.com>:
Pavel,

There is no
DECLARE TEMP CURSOR
or
DECLARE TEMP variable in PLpgSQL
and

sure .. DECLARE TEMP has no sense, = I talked about similarity DECLARE and CREATE TEMP

<= div>
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<= br> syntax:
CREATE [TEMP] VARIABLE [IF NOT EXISTS] name AS type
=C2=A0 [ DEFAULT expression ] [[NOT] NULL]
=C2=A0 [ ON TRANSACTION END { RESET | DROP } ]
=C2=A0 [ { 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.

TEMP has same functionality (and implementation= ) like our temp tables - so at session end the temp variables are destroyed= , but it can be assigned to transaction.


--94eb2c1cc5c853f931055ce42371--