Re: ON CONFLICT issues around whole row vars,

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: ON CONFLICT issues around whole row vars,
Дата
Msg-id 20151005120059.GH3685@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: ON CONFLICT issues around whole row vars,  (Peter Geoghegan <pg@heroku.com>)
Ответы Re: ON CONFLICT issues around whole row vars,
Re: ON CONFLICT issues around whole row vars,
Список pgsql-hackers
Peter, all,

* Peter Geoghegan (pg@heroku.com) wrote:
> I see now that commit 4f3b2a8883 changed things for UPDATE and DELETE
> statements, but not INSERT statements. I guess my unease is because
> that isn't entirely consistent with INSERT + RETURNING and the GRANT
> system. Logically, the only possible justification for our long
> standing INSERT and RETURNING behavior with GRANT (the fact that it
> requires SELECT privilege for rows returned, just like UPDATE and
> DELETE) is that before row insert triggers could do something secret
> (e.g. they could be security definer). It doesn't seem to be too much
> of a stretch to suppose the same should apply with RLS.

I had intended to address with policies what is addressed through
permissions with 7d8db3e, but the coverage for INSERT+RETURNING was only
done when ON CONFLICT was in use.

I've fixed that by applying the SELECT policies as WCOs for both the
INSERT and UPDATE RETURNING cases.  This matches the permissions system,
where we require SELECT rights on the table for an INSERT RETURNING
query.

Thanks!

Stephen

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: Rename withCheckOptions to insertedCheckClauses
Следующее
От: Shay Rojansky
Дата:
Сообщение: Re: Odd query execution behavior with extended protocol