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

Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>,Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>,Andrew Dunstan <andrew(at)dunslane(dot)net>, kleptog(at)svana(dot)org,simon(at)2ndquadrant(dot)com, gsstark(at)mit(dot)edu, pg(at)rbt(dot)ca,zhouqq(at)cs(dot)toronto(dot)edu, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and
Date: 2006-01-03 16:38:52
Message-ID: 20060103163852.GI82560@pervasive.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tue, Jan 03, 2006 at 11:29:02AM -0500, Tom Lane wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > In general, I do prefer that permissions be seperably grantable.  Being
> > able to grant 'truncate' permissions would be really nice.  Is the only
> > reason such permission doesn't exist due to no one working on it, or is
> > there other disagreement about it?
> 
> Lack of appetite for having forty nonstandard kinds of privilege,
> I suppose ;-)
> 
> Given that we now have roles, it's fairly easy to grant "table owner"
> to trusted people, so the use-case for special privilege types has
> dropped off dramatically IMHO.

Yeah, I hadn't thought about that. I agree; if you trust some process
enough to have MVCC-affecting rights then you should be able to trust it
with full ownership rights.
-- 
Jim C. Nasby, Sr. Engineering Consultant      jnasby(at)pervasive(dot)com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461

In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2006-01-03 16:43:23
Subject: Re: Stats collector performance improvement
Previous:From: Jim C. NasbyDate: 2006-01-03 16:35:56
Subject: Re: Stats collector performance improvement

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