On 1/6/06, Tom Lane <[EMAIL PROTECTED]> wrote: > Marko Kreen <[EMAIL PROTECTED]> writes: > > On 1/6/06, Bruce Momjian <firstname.lastname@example.org> 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 ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq