Re: AW: New SQL Datatype RECURRINGCHAR

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Hannu Krosing <hannu(at)tm(dot)ee>, Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: AW: New SQL Datatype RECURRINGCHAR
Date: 2001-07-09 17:09:03
Message-ID: 200107091709.f69H93o08140@jupiter.us.greatbridge.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Hannu Krosing <hannu(at)tm(dot)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(at)Yahoo(dot)com #

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2001-07-09 18:35:49 Re: AW: pg_index.indislossy
Previous Message Tom Lane 2001-07-09 14:50:34 Re: AW: New SQL Datatype RECURRINGCHAR