Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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

> * 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>
> 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


pgsql-hackers by date

Next:From: Bruce MomjianDate: 2006-02-03 13:51:06
Subject: Re: [HACKERS] Some platform-specific MemSet research
Previous:From: Chris CampbellDate: 2006-02-03 13:47:05
Subject: Re: Multiple logical databases

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group