Re: [HACKERS] proposal: session server side variables

Поиск
Список
Период
Сортировка
От Fabien COELHO
Тема Re: [HACKERS] proposal: session server side variables
Дата
Msg-id alpine.DEB.2.20.1702030659170.3762@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
Hello Pavel,

> The @1 area is partially solved by psql session variables or by pgAdmin
> scripting functionality. @2 is partially solved by GUC but without
> possibility to set a access rights.
>
> I didn't found any implementation of XA variables [...]

I did: GUCs in PostgreSQL are an implementation of transactional session 
variables.

As I wrote on the thread, given the "security check" use case, the safe 
alternative to transactional session variables is to have nested 
transactions. This seems like a far away prospect for pg, but is a reality 
for Oracle, DB2 and some others that have untransactional session 
variables, so at least it is safe in their case, if not elegant.

My "hard" opinion is that providing an unsafe by default feature (i.e. 
which works as in some particular cases, but may fail silently if the 
transaction fails), especially for a security related use case which 
motivates the whole feature addition, is a very bad idea for the product. 
If a committer likes it anyway, good for you.

Other opinions I expressed on the thread are somehow "softer", i.e. even 
if I think that there are better (simpler, easier) alternatives, these are 
only alternatives.

-- 
Fabien.



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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] proposal: session server side variables
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: [HACKERS] Packages: Again