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

Re: patch: Add a separate TRUNCATE permission

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>,PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: patch: Add a separate TRUNCATE permission
Date: 2008-07-29 13:11:24
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> > We've been through this before, I believe..  The concern is that it
> > chews up another bit in the acl structure, leaving not a huge number
> > left.  My suggested approach to fixing this was to split the "grantable"
> > bits up from the regular usage bits.  That's, unfortunately, a
> > non-trivial amount of work, however.
> Writing this patch was more of a "learn the PostgreSQL source" project
> for me than a feature that I, personally, have a need for, so I have
> no dog in this race other than that, if the feature was actually not
> wanted, then it shouldn't be on the TODO list, possibly causing people
> to waste time implementing it.  :-)

Oh, it's wanted, I've been asking after it for 3 years.  The problem is
just in getting people to agree to address it in this way, or if not to
accept some other way to address it (in which case the TODO should be
updated to reflect that).

> The question of using up all the bits seems purely speculative to me
> at this point.  I agree that we don't want to fritter them away, but
> this is the only TODO item proposes using any of those bits.  Tom's
> complaint about your patch seems to have been that it uses three of
> the five remaining ACL bits; this patch uses only one, and arguably
> TRUNCATE is more like a DML command than a utility command (which, as
> Tom pointed out, there are certainly too many of to ever allocate a
> bit for each one).

With the advent of autovacuum, my additional permissions for vacuum and
analyze are much less necessary.  I'm fine with just adding a permission
for truncate.

> I would argue that if we're ever going to start adding permissions for
> things like those types of utility command then we ought to create
> some separate mechanism for storing permissions that are not likely to
> need to be checked very frequently.  Then things like INSERT and
> UPDATE that happen often can benefit from a 16-bit field, and things
> like ANALYZE and ADD COLUMN that are only executed occasionally can
> use a separate, more heavy-weight mechanism.

That's along the same lines as I was proposing, except I would put all
of the "grantable" options in the "not often needed" column, which would
give us a full 32-bit field for "common" permissions.

> In any event, however we ultimately decide to implement it, we don't
> need to solve this problem now.


> > I think someone else submitted a patch for it last year too, actually.
> I talked about submitting one last year but didn't actually do it
> since it seemed to be the wrong point in the development cycle.

That might have been it, not sure.



In response to

pgsql-hackers by date

Next:From: Jorgen Austvik - Sun NorwayDate: 2008-07-29 13:16:38
Subject: pg_regress inputdir
Previous:From: Stephen FrostDate: 2008-07-29 13:03:47
Subject: Re: patch: Add a separate TRUNCATE permission

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