Simon Riggs <simon@2ndQuadrant.com> writes:
> On 9 January 2013 21:21, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> This sounds like rather a lot of work to create a behavior that doesn't
>> solve the originally-complained-of usability problem. All it does is
>> make things even more complicated, and add an extra step for the DBA
>> who's just trying to set temp_tablespaces to something useful.
> There is already an extra step to GRANT the CREATE privilege, so how
> does this change things?
The point is that it didn't occur to Stephen that putting
temp_tablespaces = 'foo, bar' into postgresql.conf should require
doing GRANT CREATE TO PUBLIC on those tablespaces in order to be
effective. Changing the situation so that instead he needs to do
GRANT TEMP TO PUBLIC does not make it one whit more usable.
All that that will really accomplish is to break grant methods that are
working in (other people's) existing installations; ie if someone has
code that does know about the GRANT CREATE requirement, he will not
thank us if he suddenly has to spell it GRANT TEMP in the next release.
If we were designing this from scratch I'd agree that a separate TEMP
privilege would be a good thing. But bolting one on now is likely
to create more problems than it fixes. Particularly since it doesn't
actually fix any of the concrete problems enumerated in this thread.
I continue to think that getting rid of the privilege check would be
a more useful answer than changing which privilege is tested.
regards, tom lane
