Re: [HACKERS] Inconsistent syntax in GRANT

On 1/6/06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Marko Kreen <markokr(at)gmail(dot)com> writes:
> > On 1/6/06, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> wrote:
> >> Uh, logically, yes, but practially currval just reads/SELECTs, while
> >> nextval modifies/UPDATEs.
>
> > Yeah, thats the mechanics behind it, but the currval() only
> > works if the user was already able to call nextval(), so I see
> > no point in separating them.
>
> You are completely wrong on this, because not all the code in a session
> necessarily executes at the same privilege level. For instance, the
> nextval() might be executed inside a SECURITY DEFINER function. It
> might be reasonable to give code outside that function the right to see
> what had been assigned (by executing currval()) without also saying that
> it could do further nextvals().

Ah, I did not think of this. Indeed, it's useful to keep them separate.
I just wanted to point out that I see much more use to keep setval()
separate from nextval/currval. (that is - always)

> I do agree that it would be a good idea to support a privilege
> distinction between nextval() and setval().

I tried to imagine a usage scenario for setval() but only
single-user bulk data load comes in mind. Is there any
actual scenario where it could be useful in multi-user
setting?

> >> Oh, interesting. We could easily have INSERT control that if we wanted,
> >> but I think you have to make a clear use case to override the risk of
> >> breaking applications.
>
> There is no backwards-compatibility risk, because we'd still have the
> old GRANT ON TABLE syntax grant both underlying rights. You'd have to
> use the new syntax to get to a state where you had nextval but not
> setval privilege or vice versa.

Good idea.

--
marko