Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > Zeugswetter Andreas SB wrote:
> >> The most prominent of the "interesting uses" probably beeing when the views
> >> are part of the authorization system, since views are the only standardized
> >> mechanism to restrict access at the row level.
>
> > True, and often the views can be restricted to insert only data that
> > will be visible using this view.
>
> Right. The interesting question is whether an automatic rule creator
> could be expected to derive the correct restrictions on
> insert/update/delete given the WHERE clause of the view. Insert/delete
> might not be too bad (at first thought, requiring the inserted/deleted
> rows to pass the WHERE condition would do), but I'm not so sure about
> update. Is it sufficient to require both the old and new states of the
> row to pass the WHERE condition?
Yes, no other chance. Remember that the rule on SELECT is
allways applied to the scan that looks for the rows to
update, so you'd never have a chance to hit other rows
through the view.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== [EMAIL PROTECTED] #
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
