Re: [HACKERS] Inconsistent syntax in GRANT
От | Marko Kreen |
---|---|
Тема | Re: [HACKERS] Inconsistent syntax in GRANT |
Дата | |
Msg-id | e51f66da0601061106l314b6c25g57d68f43e394241b@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Inconsistent syntax in GRANT (Bruno Wolff III <bruno@wolff.to>) |
Ответы |
Re: [HACKERS] Inconsistent syntax in GRANT
|
Список | pgsql-patches |
On 1/6/06, Bruno Wolff III <bruno@wolff.to> wrote: > On Fri, Jan 06, 2006 at 19:11:27 +0200, > Marko Kreen <markokr@gmail.com> wrote: > > On 1/6/06, Bruce Momjian <pgman@candle.pha.pa.us> wrote: > > > > Considering there's no currval() without nextval(), what point > > is disallowing currval() when user is able to call nextval()? > > > > I rather want to allow nextval/currval and disable setval as it > > allows regular user to DoS the database. > > What I was thinking with this, is that you might allow someone the ability > to insert records into a table which would make use of nextval, but not > allow them to run nextval directly. But after inserting a record allow them > to use currval to see what value was assigned. > People could still mess with things by doing INSERTs and aborting the > transaction, so this may not be the best example for why you would want this. This is similar to Tom's scenario. I'm not against keeping them separate. But my question is rather - is there any scenario where setval() should go with nextval()? It seems that their pairing is an accident and should be fixed. -- marko
В списке pgsql-patches по дате отправления: