On Mon, Feb 16, 2009 at 11:43 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> I'm a little bothered by this issue with respect to INSERT, UPDATE,
>> and DELETE, since it's possible that I have permission to see rows but
>> not updated them, and it would be a little weird if select and update
>> with equivalent where clauses operated on different sets of records
>> (although that can happen anyway, because of BEFORE triggers, and it's
>> pretty irritating). It's not clear that there's a clean solution
>> here, but it's at least food for thought.
>
> 80% of the problem here is exactly that the proposed solution doesn't
> seem very semantically clean. And once we accept it we're going to be
> stuck with it for a long time --- compare for instance the multiple
> serious annoyances with RULEs, which we can't fix easily because of
> backwards compatibility considerations.
I've found rules in their current form to be nearly useless, except
for views, which are wonderful. I do everything else with triggers.
With reference to row-level security, most of the complaining about
this feature has been along the lines of "I don't like the idea that
rows get filtered from my result-set that I didn't ask to have
filtered". To me, the fact that you didn't have to ask seems like a
huge convenience, and I can't imagine why you'd want it otherwise.
Sure, the behavior needs to be documented, but that doesn't seem like
a big deal.
There may well be more substantive issues here but I've been following
this discussion fairly closely and I don't have a clear understanding
of what they are.
...Robert