Re: [HACKERS] proposal: session server side variables
От | Fabien COELHO |
---|---|
Тема | Re: [HACKERS] proposal: session server side variables |
Дата | |
Msg-id | alpine.DEB.2.20.1701031839280.3802@lancre обсуждение исходный текст |
Ответ на | Re: [HACKERS] proposal: session server side variables (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: [HACKERS] proposal: session server side variables
|
Список | pgsql-hackers |
>> ****** PLEASE ****** >> COULD YOU REMOVE THE PARTS OF EMAILS YOU ARE NOT RESPONDING TO WHEN >> REPLYING IN THE THREAD? >> ****** THANKS ****** Hmmm. It seems that you can't. You should, really. >>> If you use patterns that I wrote - the security context will be valid >>> always. >> >> No: This pattern assumes that operations started in the "TRY" zone >> cannot fail later on... This assumption is false because of possible >> deferred triggers for instance. See attached example: > > ok .. it is pretty artificial, but ok. Good. We seem to agree that some kind of transactional support is needed for the use case, which is pretty logical. > In this case the reset to NULL on ROLLBACK should be enough. Probably. So I expect that you are going to update your proposal somehow to provide some transactional properties. Note that if you have some mecanism for doing a NULL on rollback, then why not just keep and reset the previous value if needed? This just means that you have a transactional variable, which is fine from my point of view. As I already wrote, session variable are memory only, so transactional does not involve costs such as WAL. Also note that user-defined GUCs already implements the transactional property, so probably the mecanism is already available and can be reused. -- Fabien.
В списке pgsql-hackers по дате отправления: