Re: proposal: schema variables

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
>

In response to

Browse pgsql-hackers by date

  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

Browse pgsql-performance by date

  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