MIME-Version: 1.0
In-Reply-To: <58C95E69-F94E-46E0-98B5-8F52454B4403@gmail.com>
References: 
 <CAFj8pRDY+m9OOxfO10R7J0PAkCCauM-TweaTrdsrsLGMb1VbEQ@mail.gmail.com>
 <58C95E69-F94E-46E0-98B5-8F52454B4403@gmail.com>
From: Pavel Stehule <pavel.stehule@gmail.com>
Date: Wed, 1 Nov 2017 20:19:48 +0100
Message-ID: 
 <CAFj8pRC3Eq1xGZ9F7LsqXnyh_851EL7ReoZfE0BxJm4GFVMk7w@mail.gmail.com>
Subject: Re: proposal: schema variables
To: Mark Dilger <hornschnorter@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Content-Type: multipart/alternative; boundary="94eb2c1cc5c8b5898b055cf0c372"
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

--94eb2c1cc5c8b5898b055cf0c372
Content-Type: text/plain; charset="UTF-8"

2017-11-01 19:03 GMT+01:00 Mark Dilger <hornschnorter@gmail.com>:

>
> > Comments, notes?
>
> How would variables behave on transaction rollback?
>
> CREATE TEMP VARIABLE myvar;
> SET myvar := 1;
> BEGIN;
> SET myvar := 2;
> COMMIT;
> BEGIN;
> SET myvar := 3;
> ROLLBACK;
> SELECT myvar;
>
> How would variables behave when modified in a procedure
> that aborts rather than returning cleanly?
>
>
The result is 3

When you create variable like you did, then there are not any relation
between variable content and transactions. Almost every where session -
package - schema variables are untransactional. It can be changed, but with
negative impact on performance - so I propose relative simply solution -
reset to default on rollback, when variables was changed in transaction -
but it is not default behave.

Variables are variables like you know from PlpgSQL. But the holder is not
the plpgsql function. The holder is a schema in this case. The variable
(meta) is permanent. The content of variable is session based
untransactional.

Regards

Pavel


> mark
>

--94eb2c1cc5c8b5898b055cf0c372
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">2017-11-01 19:03 GMT+01:00 Mark Dilger <span dir=3D"ltr">&lt;<a href=3D=
"mailto:hornschnorter@gmail.com" target=3D"_blank">hornschnorter@gmail.com<=
/a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
&gt; Comments, notes?<br>
<br>
How would variables behave on transaction rollback?<br>
<br>
CREATE TEMP VARIABLE myvar;<br>
SET myvar :=3D 1;<br>
BEGIN;<br>
SET myvar :=3D 2;<br>
COMMIT;<br>
BEGIN;<br>
SET myvar :=3D 3;<br>
ROLLBACK;<br>
SELECT myvar;<br>
<br>
How would variables behave when modified in a procedure<br>
that aborts rather than returning cleanly?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></blockquo=
te><div><br></div><div>The result is 3<br></div><div><br></div><div>When yo=
u create variable like you did, then there are not any relation between var=
iable content and transactions. Almost every where session - package - sche=
ma variables are untransactional. It can be changed, but with negative impa=
ct on performance - so I propose relative simply solution - reset to defaul=
t on rollback, when variables was changed in transaction - but it is not de=
fault behave.<br></div><div><br></div><div>Variables are variables like you=
 know from PlpgSQL. But the holder is not the plpgsql function. The holder =
is a schema in this case. The variable (meta) is permanent. The content of =
variable is session based untransactional.</div><div><br></div><div>Regards=
</div><div><br></div><div>Pavel<br> </div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><span class=3D"HOEnZb"><font color=3D"#888888">
<br>
mark<br>
</font></span></blockquote></div><br></div></div>

--94eb2c1cc5c8b5898b055cf0c372--