Re: AW: New SQL Datatype RECURRINGCHAR

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?

SQL92 gives this restriction on WHERE clauses for updatable views:

d) If the <table expression> immediately contained in QS imme-
diately contains a <where clause> WC, then no leaf generally
underlying table of QS shall be a generally underlying table
of any <query expression> contained in WC.

which conveys nothing to my mind :-(, except that they're restricting
sub-SELECTs in WHERE somehow. Can anyone translate that into English?

regards, tom lane