From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Mark Dilger <hornschnorter(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: proposal: schema variables |
Date: | 2017-11-01 19:19:48 |
Message-ID: | CAFj8pRC3Eq1xGZ9F7LsqXnyh_851EL7ReoZfE0BxJm4GFVMk7w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
2017-11-01 19:03 GMT+01:00 Mark Dilger <hornschnorter(at)gmail(dot)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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2017-11-01 21:05:58 | Re: Custom compression methods |
Previous Message | Peter Eisentraut | 2017-11-01 18:47:29 | Re: [PATCH] Pageinspect - add functions on GIN and GiST indexes from gevel |
From | Date | Subject | |
---|---|---|---|
Next Message | Gilles Darold | 2017-11-01 22:13:47 | Re: proposal: schema variables |
Previous Message | Mark Dilger | 2017-11-01 18:03:28 | Re: proposal: schema variables |