Re: [HACKERS] Inconsistent syntax in GRANT - Mailing list pgsql-patches

From Tom Lane
Subject Re: [HACKERS] Inconsistent syntax in GRANT
Date
Msg-id 23471.1136588675@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Inconsistent syntax in GRANT  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: [HACKERS] Inconsistent syntax in GRANT
Re: [HACKERS] Inconsistent syntax in GRANT
List pgsql-patches
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> FYI, we could support USAGE just on sequences, and have it map to
> UPDATE, but pg_dump it out as USAGE.

It seems the spec doesn't cover setval() and currval(), which is not
too surprising given those aren't standard.

Here is a proposal:

SELECT priv -> allows currval() and SELECT * FROM seq

USAGE priv -> allows nextval() (required by SQL2003)

UPDATE priv -> allows setval() and nextval()

I was originally thinking of a separate privilege bit for setval(), but
that's sort of silly, as you can get (approximately) the effect of
nextval() via setval().  Not much point in prohibiting nextval() to
someone who can do setval().

This is 100% upward compatible with our current definition, and it meets
both the SQL spec and Marko's desire to have a way of granting only
nextval() privilege.

BTW, what about lastval()?  I'm not sure we can usefully associate any
privilege check with that, since it's not clear which sequence it
applies to.  Does it make sense to remember what sequence the value came
from and privilege-check against that, or is that just too weird?

            regards, tom lane

pgsql-patches by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Inconsistent syntax in GRANT
Next
From: Josh Berkus
Date:
Subject: Re: [HACKERS] Inconsistent syntax in GRANT