Tom Lane wrote:
> Hannu Krosing <hannu@tm.ee> 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. #
#================================================== JanWieck@Yahoo.com #
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
