Simon Riggs <simon@2ndQuadrant.com> writes:
> On 9 January 2013 22:09, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> [ shrug... ] That's weird, ie unlike the behavior of other privileges,
>> and it *still* doesn't fix any of the problems Stephen complained of.
> I think we're having a disconnection half hour?
> The privs could be seen as CREATE_ANY or CREATE_TEMP_ONLY. One is a
> superset of the other, just like granting ANY is a superset of other
> privs.
> My view is it would fix the root cause of the problem, as explained.
No; what it would do is provide a feature we don't currently have, ie
the ability to let unprivileged users select a specific tablespace for
temp files but not real tables. That may or may not be a useful feature
(I do not recall any previous requests for it, and it's not immediately
obvious why someone should be allowed to create 100GB of temp files but
no not-temp files). But it does *not* address either of the key points
that Stephen raised to begin with, which to my mind were:
(1) It's unintuitive that setting temp_tablespaces in postgresql.conf
isn't sufficient to make sessions use those tablespaces for temp files.
(This is a definitional problem.)
(2) The current coding of the permissions tests is actively wrong,
in that changes of role context in the backend don't affect what
happens. (This is an implementation problem, but that doesn't mean
it's simple to fix. Also, even if it acted as one might expect, there
would still be unfortunate usability issues in sessions that actually
do switch roles, as Stephen illustrated.)
Just checking a different permissions bit won't do a thing for either
of those problems. I continue to suggest that the most effective fix
for those issues is to reconsider what we want the overall behavior
of temp_tablespaces to be in the first place. If we consider it to be
controlled primarily by the DBA and not individual users, then we can
make both (1) and (2) go away very easily.
regards, tom lane
