Re: [HACKERS] proposal: session server side variables

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: [HACKERS] proposal: session server side variables
Дата
Msg-id CAFj8pRDwV8BWnvEamZtZeTZGcf+qEcr5svfu0LQUGuKUx1APjw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] proposal: session server side variables  (Fabien COELHO <coelho@cri.ensmp.fr>)
Ответы Re: [HACKERS] proposal: session server side variables  (Fabien COELHO <coelho@cri.ensmp.fr>)
Список pgsql-hackers
Дерево обсуждения


2017-02-03 11:18 GMT+01:00 Fabien COELHO <coelho@cri.ensmp.fr>:

We can implement XA support for variables, ale I don't think so default should be XA.

 I was answering your question, which is what you can do about the feedback: take the one hard/strong point into account in your proposal.

You do not want to do that. Too bad.

The argument that you keep on repeating about "other software do it like that so it is the good way" do not work because these software (Oracle, DB2, ...) have features unavailable to postgres which mitigate the issue I'm raising, and there is no such mitigation in postgres.

Note that you can proceed and simply ignore my negative opinion, which will stay negative till these "secure" variables are transactional by default, or till nested/autonomous transactions are provided by postgres.

I'll work on my proposal in v11 time. Maybe in this time Postgres will support autonomous transactions. 

The variables syntax should be better integrated to core - it should be implemented without getter/setter functions. I am not sure If statement SET can be enhanced to allows the work with session variables without some conflicts, but we will see. 

Regards

Pavel


 


--
Fabien.

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

Предыдущее
От: Corey Huinker
Дата:
Сообщение: Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands:\quit_if, \quit_unless)
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: [HACKERS] [PROPOSAL] Temporal query processing with range types