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
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
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
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
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: