On Tue, Oct 24, 2023 at 1:46 PM Jeff Davis <pg...@j-davis.com> wrote: > Perhaps the idea is that if there are constraints involved, the failure > or success of an INSERT/UPDATE/DELETE could leak information that you > don't have privileges to read.
My recollection of this topic is pretty hazy, but like Tom, I seem to remember it being intentional, and I think the reason had something to do with wanting the slice of a RLS-protect table that you can see to feel like a complete table. When you update a row in a table all of which is visible to you, the updated row can never vanish as a result of that update, so it was thought, if I remember correctly, that this should also be true here. It's also similar to what happens if an updatable view has WITH CHECK OPTION, and I think that was part of the precedent as well. I don't know whether or not the constraint issue that you mention here was also part of the concern, but it may have been. This was all quite a while ago... -- Robert Haas EDB: http://www.enterprisedb.com
