From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
Cc: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, Gilles Darold <gilles(dot)darold(at)dalibo(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: [HACKERS] proposal: schema variables |
Date: | 2018-09-06 08:30:04 |
Message-ID: | CAFj8pRB+PDcKX0WJqovhxMJb=O=k4qV+EekFDKFpyVSZLzFzfA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
Hi
here is updated patch - I wrote some transactional support
I am not sure how these new features are understandable and if these
features does it better or not.
There are possibility to reset to default value when
a) any transaction is finished - the scope of value is limited by
transaction
CREATE VARIABLE foo int ON TRANSACTION END RESET;
b) when transaction finished by rollback
CREATE VARIABLE foo int ON ROLLBACK RESET
Now, when I am thinking about it, the @b is simple, but not too practical -
when some fails, then we lost a value (any transaction inside session can
fails). The @a has sense - the behave is global value (what is not possible
in Postgres now), but this value is destroyed by any unhandled exceptions,
and it cleaned on transaction end. The @b is just for information and for
discussion, but I'll remove it - because it is obscure.
The open question is syntax. PostgreSQL has already ON COMMIT xxx . It is
little bit unclean, because it has semantic "on transaction end", but if I
didn't implement @b, then ON COMMIT syntax can be used.
Regards
Pavel
Attachment | Content-Type | Size |
---|---|---|
schema-variables-180906-01.patch | text/x-patch | 208.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Chris Travers | 2018-09-06 09:08:56 | Re: Funny hang on PostgreSQL 10 during parallel index scan on slave |
Previous Message | Peter Eisentraut | 2018-09-06 08:16:07 | Re: remove ancient pre-dlopen dynloader code |
From | Date | Subject | |
---|---|---|---|
Next Message | Jeremy Schneider | 2018-09-06 15:16:29 | Re: Guideline To Resolve LWLock:SubtransControlLock |
Previous Message | Jeff Janes | 2018-09-05 16:07:15 | Re: Performance difference in accessing differrent columns in a Postgres Table |