From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Peter Geoghegan <pg(at)heroku(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: INSERT ... ON CONFLICT UPDATE and RLS |
Date: | 2015-01-07 20:17:06 |
Message-ID: | CA+TgmoaNMqVE+jwHzWjOD2fuo88ouHStZTeRr=ygKwPC=p5Y6Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jan 7, 2015 at 3:01 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> * Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
>> On Wed, Jan 7, 2015 at 4:04 AM, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)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.
I'd say: that's life. If you don't test your policies, they might not work.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2015-01-07 20:19:58 | Re: pg_basebackup fails with long tablespace paths |
Previous Message | Stephen Frost | 2015-01-07 20:09:56 | Re: Possible typo in create_policy.sgml |