Re: INSERT ... ON CONFLICT UPDATE and RLS
От | David Fetter |
---|---|
Тема | Re: INSERT ... ON CONFLICT UPDATE and RLS |
Дата | |
Msg-id | 20150108011631.GA13548@fetter.org обсуждение исходный текст |
Ответ на | Re: INSERT ... ON CONFLICT UPDATE and RLS (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: INSERT ... ON CONFLICT UPDATE and RLS
|
Список | pgsql-hackers |
On Wed, Jan 07, 2015 at 03:01:20PM -0500, Stephen Frost wrote: > * Robert Haas (robertmhaas@gmail.com) wrote: > > On Wed, Jan 7, 2015 at 4:04 AM, Dean Rasheed <dean.a.rasheed@gmail.com> wrote: > > > I think the policies applied should depend on the path taken, so if it > > > does an INSERT, then only the INSERT CHECK policy should be applied > > > (after the insert), but if it ends up doing an UPDATE, I would expect > > > the UPDATE USING policy to be applied (before the update) and the > > > UPDATE CHECK policy to be applied (after the update). I would not > > > expect the INSERT CHECK policy to be applied on the UPDATE path. > > > > I agree. > > I can certainly understand the appeal of this approach, but I don't > think it makes sense. Consider what happens later on down the road, > after the code has been written and deployed using INSERT .. ON CONFLICT > UPDATE where 99% of the time only one path or the other is taken. Then > the other path is taken and suddenly the exact same command and row ends > up returning errors. Additional testing should have been done to check > if that happens, of course, but I really don't like the idea that the > exact same command, with the exact same policies, would succeed or fail, > due to policies, based on the data in the database. There's precedent. Unique constraints, for example. Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
В списке pgsql-hackers по дате отправления: