Re: [HACKERS] proposal: session server side variables

Поиск
Список
Период
Сортировка
От Fabien COELHO
Тема Re: [HACKERS] proposal: session server side variables
Дата
Msg-id alpine.DEB.2.20.1701041917160.22281@lancre
обсуждение исходный текст
Ответ на Re: [HACKERS] proposal: session server side variables  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: [HACKERS] proposal: session server side variables  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-hackers
> [...] It is on critical path, so every check increase computer time for 
> transaction end.

Hmmm... Everything executed is on the critical path...

>> It is a very good thing that GUCs are transactional, and this should not
>> be changed, it is a useful feature! Much more useful than non transactional.
>
> Personally, I never used - although I using often nesting

Your position is contradictory:

First you put forward a variable-with-permissions for a special use case, 
you insist that correctness is key and must be checked with static 
analysis tools that audit codes, that dynamic variables are too ugly for 
the purpose. Fine, even if I disagree with some details, there is some 
logic in that: security, audit, checks... why not.

Then when one shows that correctness requires that the variable is 
transactional, this is not so important anymore based on the fact that 
some big companies do not do it like that, and suddenly it is enough that 
it probably works sometimes. And when the fact that pg already supports 
transactional variables is pointed out, just what the use case needs... 
then you suggest to remove the property.

What can I say? You've lost me, really.

-- 
Fabien.



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] An isolation test for SERIALIZABLE READ ONLY DEFERRABLE
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: [HACKERS] merging some features from plpgsql2 project