Re: [HACKERS] proposal: session server side variables
| От | Pavel Stehule |
|---|---|
| Тема | Re: [HACKERS] proposal: session server side variables |
| Дата | |
| Msg-id | CAFj8pRD-D_OSgniYWfX+DzH-XSsi3_1BU5hktHx23q8sCR6Ebg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] proposal: session server side variables (Pavel Stehule <pavel.stehule@gmail.com>) |
| Ответы |
Re: [HACKERS] proposal: session server side variables
Re: [HACKERS] proposal: session server side variables Re: [HACKERS] proposal: session server side variables |
| Список | pgsql-hackers |
2017-02-01 6:42 GMT+01:00 Pavel Stehule <pavel.stehule@gmail.com>:
2017-02-01 6:05 GMT+01:00 Michael Paquier <michael.paquier@gmail.com>:On Wed, Jan 11, 2017 at 10:42 PM, Craig Ringer <craig@2ndquadrant.com> wrote:
> There is no code yet. Code review and testing is where things get firmer.
>
> My personal stance right now is that I'd like to see catalog-decared typed
> variables. I would prefer them to be transactional and would at least oppose
> anything that didn't allow future room for that capability. I'd prefer that
> non-transactional vars be clearly declared as such.
>
> In the end though... I'm not the one implementing it. I can have some
> influence through the code review process. But it's whoever steps up with a
> proposed implementation that has the biggest say. The rest of us can say yes
> or no to some degree... but nobody can make someone else implement something
> they don't want.
The last patch is from the 6th of December and does not apply anymore:
https://www.postgresql.org/message-id/CAFj8pRA9w_AujBAYdLR0U VfXwwoxhmn%2BFbNHnD3_NL% 3DJ9x3y8w%40mail.gmail.com
I don't have a better idea than marking this patch as "returned with
feedback" for now, as the thread has died 3 weeks ago as well.There is not a agreement on the form of session variables.
Today I found on net a documentation to DB2 "CREATE VARIABLE" command. I had not any idea, so this statement exists already, although it is old feature - I found a doc from 2007.
The DB2 design is very similar to my proposal - secured access, persistent metadata, unshared untransactional data limmited by session.
They doesn't use a access functions - the access is with notation schemaname.variablename. I proposed this syntax as next step in implementation.
The DB2 authors doesn't propose transactional variables - when user needs XA behave, then global temporary tables should be used.
My patch was marked as "returned with feedback". Personally, I had not a idea what can be next step and what is preferred design, if some preferred design exists. I don't know what I have to change on my proposal.
I understand, so there are two different concepts - 1. using variables for adhoc writing like T-SQL, MySQL or 2. using variables as global session objects for stored procedures.
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 or persistent variables on the world.
Regards
Pavel
RegardsPavel--
Michael
В списке pgsql-hackers по дате отправления: