Re: Schema variables - new implementation for Postgres 15

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: Schema variables - new implementation for Postgres 15
Дата
Msg-id CAFj8pRDWntu3JUix5-YNrnX0GmAYWyPOjbhxZxbQ_7QZ7x6fDw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Schema variables - new implementation for Postgres 15  (Julien Rouhaud <rjuju123@gmail.com>)
Ответы Re: Schema variables - new implementation for Postgres 15  (Julien Rouhaud <rjuju123@gmail.com>)
Список pgsql-hackers

sessionvariable.c:

+ * Although session variables are not transactional, we don't
+ * want (and we cannot) to run cleaning immediately (when we
+ * got sinval message). The value of session variables can
+ * be still used or the operation that emits cleaning can be
+ * reverted. Unfortunatelly, this check can be done only in
+ * when transaction is committed (the check against system
+ * catalog requires transaction state).

This was the original idea, but since there's now locking to make all DDL safe,
the metadata should be considered fully transactional and no session should
still be able to use a concurrently dropped variable.  Also, the invalidation
messages are not sent until the transaction is committed.  So is that approach
still needed (at least for things outside ON COMMIT DROP / ON TRANSACTION END
RESET

I think this is still necessary. The lock protects the variable against drop from the second session, but not for reverted deletion from the current session.

This implementation is due Tomas's request for

CREATE VARIABLE xx AS int;
LET xx = 100;
BEGIN;
DROP VARIABLE xx;
ROLLBACK;
SELECT xx; --> 100

and the variable still holds the last value before DROP

Personally, this is a corner case (for me, and I think so for users it is not too interesting, and important),  and this behavior is not necessary - originally I implemented just the RESET variable in this case. On the other hand, this is a nice feature, and there is an analogy with TRUNCATE behavior.

More, I promised, as a second step, implementation of optional transactional behavior of session variables. And related code is necessary for it. So I prefer to use related code without change.

Regards

Pavel

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

Предыдущее
От: Andrei Zubkov
Дата:
Сообщение: Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements
Следующее
От: Fabien COELHO
Дата:
Сообщение: Re: libpq async duplicate error results