Robert Haas wrote:
> 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.
Yes, I can provide documentations to introduce behaviors by the new
features. Any comments to point out unclear things will be helpfull
to improve them.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>