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 по дате отправления:

Предыдущее
От: Marko Kreen
Дата:
Сообщение: Re: [HACKERS] Inconsistent syntax in GRANT
Следующее
От: Joachim Wieland
Дата:
Сообщение: psql tab completion enhancements