Re: [HACKERS] proposal: schema variables

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: [HACKERS] proposal: schema variables
Дата
Msg-id CAFj8pRB+PDcKX0WJqovhxMJb=O=k4qV+EekFDKFpyVSZLzFzfA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] proposal: schema variables  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: [HACKERS] proposal: schema variables  (Fabien COELHO <coelho@cri.ensmp.fr>)
Список pgsql-hackers
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


Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: remove ancient pre-dlopen dynloader code
Следующее
От: Chris Travers
Дата:
Сообщение: Re: Funny hang on PostgreSQL 10 during parallel index scan on slave