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

From Fabien COELHO
Subject Re: [HACKERS] proposal: session server side variables
Date
Msg-id alpine.DEB.2.20.1612290831530.4911@lancre
Whole thread Raw
In response to Re: [HACKERS] proposal: session server side variables  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List pgsql-hackers
Hello Jim,

>> Yes if the private variable should be accessed. If the variable is
>> private, then it is private and nothing is needed. Idem for public.
>
> Why force the extra busywork? Just allow for them to be public.

There is no extra busywork, having possibly private session variables cost 
nearly nothing, and I'm arguing that they could be enough for Pavel 
special use case.

> For that matter, if we're going to start introducing private objects, that 
> certainly needs to be thought through.

Yep. It is a discussion.

>> One can get the permissions on special session variable wrong as well...
>> I do not see how it differs.
>
> It's a lot harder to mess up an explicit grant than it is to mess up object 
> ownership.

ISTM that it rather depends on the default permissions on the object... If 
a variable object is publicly accessible by default, then you have to take 
care about revoke & grant and you can mess up with it. Moreover, it also 
suggest that session variables could be private by default.

>>  *@db> SELECT secfunc2(); -- returns: "postgres - fabien" from both
>> sides...
>
> Perhaps I've got the restrictions on SECDEF wrong, but I know there's 
> problems with it. Certainly one issue is you can't change roles back to the 
> calling user.

It is the same with suid executable on Unix, I do not see as an issue.

> Maybe they would be workable in this case, but it's just a bunch of extra 
> busywork for the user that serves no real purpose.

Pavel special case is the purpose.

> Then IMHO what needs to happen is to have a discussion on actual syntax 
> instead of calling into question the value of the feature.

I think that the discussion should be *both* about syntax and semantics.

> Following this thread has been very painful because the communications 
> have not been very clear.

Yep. The fact that I initially missed the "half persistence" property of 
Pavel's design has not helped.

I suggest to move the discussion on the following wiki page that I have 
just bootstrapped:
    https://wiki.postgresql.org/wiki/Variable_Design

-- 
Fabien



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] Indirect indexes
Next
From: Fabien COELHO
Date:
Subject: Re: [HACKERS] proposal: session server side variables