Greg Stark <[EMAIL PROTECTED]> writes:
> I think you want to extend the SQL syntax to allow updating views, and
> implement plan nodes and executor functionality to handle them. So things
> like this works:
> UPDATE (SELECT id,val FROM t) SET val=0 where id < 100
> Then the rules you create on the views are just like the rules for SELECT,
> they simply mechanically replace the view with the view definition.
> I think this is the right approach because:
> a) I think creating the general rules to transform an update into an update on
> the underlying table will be extremely complex, and you'll only ever be
> able to handle the simplest cases. By handling the view at planning time
> you'll be able to handle arbitrarily complex cases limited only by whether
> you can come up with reasonable semantics.
Please provide an existence proof. I don't really see any basis for the
claim that this will be simpler to implement --- the semantic problems
will be the same either way.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
