On 1/6/06, Bruce Momjian <pgman@candle.pha.pa.us> wrote: > Marko Kreen wrote: > > On 1/6/06, Bruce Momjian <pgman@candle.pha.pa.us> wrote: > > > Bruno Wolff III wrote: > > > > It might be nice to split nextval and currval access as well. nextval > > > > access > > > > corresponds to INSERT and currval access to SELECT. > > > > > > Uh, that is already in the code. nextval()/setval() is UPDATE, and > > > currval() is SELECT. > > > > This seems weird. Shouldn't nextval/currval go together and setval > > separately? > > 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. In other words: there is nothing to do with only access to currval(), and with access to nextval() but not to currval() user loses only in convinience. > > Considering there's no currval() without nextval(), what point > > is disallowing currval() when user is able to call nextval()? > > Not sure. I think SET SESSION AUTHORIZATION would make it possible. /me confused, looks at docs... Huh? I really hope you are mistaken. This would mean the sequence state for currval() is kept per-user not per-backend. This would make impossible to make several connections as same user. Is Postgres really that broken? > > I rather want to allow nextval/currval and disable setval as it > > allows regular user to DoS the database. > > 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. I'd turn it around: is there any use-case for setval() for regular user? IMHO it's a admin-level operation, dangerous, and not needed for regular work. -- marko ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly