On 1/6/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> Marko Kreen <[EMAIL PROTECTED]> 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

> >> 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.


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?


Reply via email to