Marko Kreen wrote:
> On 1/6/06, Bruce Momjian <email@example.com> 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
Uh, logically, yes, but practially currval just reads/SELECTs, while
> 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.
> 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
Bruce Momjian | http://candle.pha.pa.us
firstname.lastname@example.org | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not