On Feb 3, 2006, at 02:09, Tino Wildenhain wrote:
> Well if the view does not suit your needs, why dont you use an
> set returnung function instead? Inside it you can do all the magic
> you want and still use it similar to a table or view.
That's what I'm currently doing (as explained in the first message in
the thread). But the function is a "black box" to the planner when
the query is executed -- I'd like the planner to be able to combine
the query inside the function with the outer calling query and plan
it as one big query. Like it does with views. Thus, "views with
arguments."
We're certainly not deficient in this area (set-returning functions
fill the need quite well), but a feature like this would go even
further in terms of ease-of-use and performance.
Benefits of "views with arguments" versus functions:
* Better query execution performance because the planner can plan the
whole query (rewriting the original query to replace references to
the view with the view's definition -- this is how views work today)
* PostgreSQL-tracked dependancies: views create dependencies on the
relations they reference -- functions do not
* Don't have to manually maintain a composite type for the return value
Basically, better performance and easier administration.
Thanks!
- Chris