From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
---|---|
To: | Chris Campbell <chris(at)bignerdranch(dot)com> |
Cc: | Tino Wildenhain <tino(at)wildenhain(dot)de>, Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Passing arguments to views |
Date: | 2006-02-03 13:50:56 |
Message-ID: | 20060203135056.GC5009@svana.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Feb 03, 2006 at 08:33:23AM -0500, Chris Campbell wrote:
> 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.
Hmm, we actually do inline SQL functions under certain situations, but
only for "simple" queries (see inline_function in
optimizer/util/clauses.c). One approach would be to expand that
function to inline more complicated things.
> 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)
Well, the inlining would acheive the same effect.
> * PostgreSQL-tracked dependancies: views create dependencies on the
> relations they reference -- functions do not
Technically a bug. We should be tracking dependancies for functions
anyway.
> * Don't have to manually maintain a composite type for the return value
This is a good point. Though with syntactic sugar you could work around
this too...
Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2006-02-03 13:51:06 | Re: [HACKERS] Some platform-specific MemSet research |
Previous Message | Chris Campbell | 2006-02-03 13:47:05 | Re: Multiple logical databases |