I also think that a view is supposed to be just that -- a *view* of
underlying data, which in no way modifies the data. I don't know much
about the design ideas behind SQL, but I think this view of views
(haha) is an underlying assumption. If you are modifying data when
you do a select on a view, you are probably not using SQL the way it
was intended (not that that is a bad thing, but ...)
Postgresql has "rules" which I *think* can rewrite select statements.
Rules are kind of a pain, but maybe what you want.
On 2/24/07, Webb Sprague <[EMAIL PROTECTED]> wrote:
>. I have _additional_
> constraints to place on modifications done through
> views, and trickyness involved in modifying the
> underlying tables.
Write a function foo that returns a set, then a view: "create view as
select * from foo()". Incorporate all the trickiness in the function,
including variables, multiple temporary tables, whatever you need.
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
