From: | Peter Geoghegan <pg(at)heroku(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: ON CONFLICT issues around whole row vars, |
Date: | 2015-10-01 23:19:57 |
Message-ID: | CAM3SWZSPUxA9CP3m_kVti8USemV6XZsQz0mi33yEAQiLQt02+w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Oct 1, 2015 at 3:53 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>> I specifically remember discussing this with you off list (on IM,
>> roughly a couple of weeks prior to initial commit). I recommended that
>> we err towards a more restrictive behavior in the absence of any
>> strong principle pushing us one way or the other. You seemed to agree.
>
> I don't think this really is comparable. Comparing this with a plain
> INSERT or UPDATE this would be akin to running RLS on the RETURNING
> tuple - which we currently don't.
>
> I think this is was just a bug.
Maybe that's the problem here; I still thought that we were planning
on changing RLS in this regard, but it actually seems we changed
course, looking at the 9.5 open items list.
I would say that that's a clear divergence between RLS and column
privileges. That might be fine, but it doesn't match my prior
understanding of RLS (or, more accurately, how it was likely to change
pre-release).
If that's the design that we want for RLS across the board, then I'm
happy to defer to that decision.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2015-10-01 23:26:07 | Re: ON CONFLICT issues around whole row vars, |
Previous Message | Michael Paquier | 2015-10-01 23:19:53 | Re: pg_dump LOCK TABLE ONLY question |