On 1/6/06, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Marko Kreen <markokr@gmail.com> writes:
> > On 1/6/06, Bruce Momjian <pgman@candle.pha.pa.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