Robert Haas wrote:
On Mon, Feb 16, 2009 at 11:43 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
Robert Haas <robertmh...@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 <kai...@ak.jp.nec.com>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
