Re: [HACKERS] Inconsistent syntax in GRANT

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Inconsistent syntax in GRANT
Дата
Msg-id 23471.1136588675@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Inconsistent syntax in GRANT  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: [HACKERS] Inconsistent syntax in GRANT  (Josh Berkus <josh@agliodbs.com>)
Re: [HACKERS] Inconsistent syntax in GRANT  (Marko Kreen <markokr@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: [HACKERS] Inconsistent syntax in GRANT
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: [HACKERS] Inconsistent syntax in GRANT