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().
I do agree that it would be a good idea to support a privilege
distinction between nextval() and setval().
>> 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.
regards, tom lane