Re: [HACKERS] proposal: session server side variables - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: [HACKERS] proposal: session server side variables
Date
Msg-id CAFj8pRD-D_OSgniYWfX+DzH-XSsi3_1BU5hktHx23q8sCR6Ebg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] proposal: session server side variables  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: [HACKERS] proposal: session server side variables
Re: [HACKERS] proposal: session server side variables
Re: [HACKERS] proposal: session server side variables
List 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_AujBAYdLR0UVfXwwoxhmn%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

 

Regards

Pavel
 
--
Michael


pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: [HACKERS] Logical Replication and Character encoding
Next
From: Fabien COELHO
Date:
Subject: Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands:\quit_if, \quit_unless)