Re: Index build temp files

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Index build temp files
Date: 2013-01-09 22:47:15
Message-ID: CA+U5nML9gxJ=TXB1CU6RzqO4=P6oZOHC2CPgZLs1frkJ0e68-A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 9 January 2013 22:09, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
>> On 9 January 2013 21:42, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2013-01-09 23:05:07 Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)
Previous Message Tom Lane 2013-01-09 22:35:15 Re: [PATCH] unified frontend support for pg_malloc et al and palloc/pfree mulation (was xlogreader-v4)