Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group