Re: Index build temp files - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Index build temp files
Date
Msg-id CA+U5nML9gxJ=TXB1CU6RzqO4=P6oZOHC2CPgZLs1frkJ0e68-A@mail.gmail.com
Whole thread Raw
In response to Re: Index build temp files  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Index build temp files
List pgsql-hackers
On 9 January 2013 22:09, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
>> On 9 January 2013 21:42, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> 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.
>
>> I wasn't suggesting that we test for TEMP instead of CREATE; what I
>> meant was we would test for CREATE *OR* TEMP to give more options for
>> management.
>
> [ 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.
If you wanted to make TEMP active by default, we can do that.

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)
Next
From: Andres Freund
Date:
Subject: Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)