Re: [HACKERS] proposal: session server side variables
| От | Pavel Stehule |
|---|---|
| Тема | Re: [HACKERS] proposal: session server side variables |
| Дата | |
| Msg-id | CAFj8pRBygLXpZ3yMO+0H-Uc9wv0z5wf3872dgMO61JJL74FJHA@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>)
Re: [HACKERS] proposal: session server side variables (Pavel Stehule <pavel.stehule@gmail.com>) |
| Список | pgsql-hackers |
2017-02-03 7:25 GMT+01:00 Fabien COELHO <coelho@cri.ensmp.fr>:
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.
GUC was not designed for usage in stored procedures.
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.
You have everywhere the fence between transactional/untransactional - and you can see some unwanted artefacts there. The world "secure" just means - a possibility to set access rights - nothing more, nothing less.
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.
I respect to your opinion and I understand - I have a similar strong opinion on packages in Postgres. In this case I prefer a common implementation - and common expectation.
When some feature is PostgreSQL original, then we can design how we can. But when we implement some feature that exists already, then we should to respect some previous, older major implementation.
The great example is our implementation of OUT parameters in PL. The idea is great - modern languages use it Golang, Rust. But in PL area is unique, different. One from significant issues migrations to Postgres, Postgres adoptions is this small feature.
The people who is working with stored procedures doesn't expect XA behave, overhead when they working with some objects named "variables". We can implement XA support for variables, ale I don't think so default should be XA. Only few cases where variables can be used are are XA sensitive.
Regards
Pavel
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 по дате отправления: