Re: Passing arguments to views

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.

In response to

Responses

Browse pgsql-hackers by date

  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