Re: [HACKERS] proposal: session server side variables
От | Fabien COELHO |
---|---|
Тема | Re: [HACKERS] proposal: session server side variables |
Дата | |
Msg-id | alpine.DEB.2.20.1701021613480.26374@lancre обсуждение исходный текст |
Ответ на | proposal: session server side variables (Pavel Stehule <pavel.stehule@gmail.com>) |
Список | pgsql-hackers |
>>> Attention! rollback is significantly expensive than RESET. >> >> I'm quite unclear about the difference... Transactional for an unshared >> only-in-memory session object is probably easy to implement, no WAL is >> needed... So I do not see the difference > you have to store previous value This does not fully answer my question. Maybe RESET would put NULL instead of the previous value in a rollback? If so, I must admit that I do not see any fundamental issue with holding temporarily the initial value of an in-memory session variables so as to be able to rool it back if required... >>> There are no any product where variables are transactional - we should >>> not to create wheel. >> >> Well, AFAICS PostgreSQL GUCs are transactional. > that is exception .. That is just logic: if you make an argument based on "it does not exist", then the argument is void if someone produces a counter example. > show me some transactiinal variables from msql, oracle, db2 I do not really know these three particular products. All I can say is that from a semantical point of view the contents of any one-row temporary relation is somehow a transactional session variable. However I do not know whether the 3 cited products have temporary tables, this is just a guess. -- Fabien.
В списке pgsql-hackers по дате отправления: