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

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

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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:21:37
Message-ID: 20060103162137.GO6026@ns.snowman.net (view raw or flat)
Thread:
Lists: pgsql-hackers
* Jim C. Nasby (jnasby(at)pervasive(dot)com) wrote:
> I dislike restricting to super-user, and to some extent even table
> owner. The reason is that if you have some automated batch process, you
> don't want that process running as a superuser. Also, it is often
> awkward to require that the user running that batch own the table.

The owner of the table could be a role which the batch runner is part of
(along with whatever other roles you wish to have 'owner'-level
permissions on the table).

> I'd much rather see this as a grantable permission on the table. (The
> same is true with truncate, btw). This way, if a DBA knew he could trust
> a specific role, he could allow for these operations on a specific
> table.

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?

	Thanks,

		Stephen

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2006-01-03 16:26:51
Subject: Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and
Previous:From: Jim C. NasbyDate: 2006-01-03 16:18:12
Subject: Re: Why don't we allow DNS names in pg_hba.conf?

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