Re: [HACKERS] proposal: session server side variables (fwd)

Поиск
Список
Период
Сортировка
От Fabien COELHO
Тема Re: [HACKERS] proposal: session server side variables (fwd)
Дата
Msg-id alpine.DEB.2.20.1701081007440.10378@lancre
обсуждение исходный текст
Ответ на Re: [HACKERS] proposal: session server side variables (fwd)  (Fabien COELHO <coelho@cri.ensmp.fr>)
Список pgsql-hackers
Hello Bruce,

>>>>> Good. So we seem to agree that GUCS are transactional?
>
> Uh, I think it is a missing feature, i.e.:
>
>     https://wiki.postgresql.org/wiki/Todo#Administration
>     Have custom variables be transaction-safe
>     https://www.postgresql.org/message-id/4B577E9F.8000505@dunslane.net

Hmmm, that is a subtle one:-)

After more testing, the current status is that the values of existing 
user-defined parameters is cleanly transactional, as already tested:
 fabien=# SET x.x = 'before'; fabien=# BEGIN; fabien=# SET x.x = 'inside'; fabien=# ROLLBACK; fabien=# SHOW x.x; --
'before'

This is what I meant by "GUCs are transactional".

However, as you point out, the existence of the parameter is not: If it is 
created within an aborted transaction then it still exists afterwards:
 fabien=# SHOW z.z; ERROR:  unrecognized configuration parameter "z.z" fabien=# BEGIN; fabien=# SET z.z = 'yep';
fabien=#ROLLBACK; fabien=# SHOW z.z; -- no error, empty string shown
 

So GUCs are... half-transactional? :-)

From the security-related use case perspective, this half transactionality 
is enough, but it is not very clean. Does not look like a very big issue 
to fix, it just seems that nobody bothered in the last 6 years...

-- 
Fabien.



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

Предыдущее
От: Joel Jacobson
Дата:
Сообщение: [HACKERS] RustgreSQL
Следующее
От: Dmitry Dolgov
Дата:
Сообщение: Re: [HACKERS] [PATCH] Generic type subscription