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

Re: Passing arguments to views

From: Chris Campbell <chris(at)bignerdranch(dot)com>
To: Tino Wildenhain <tino(at)wildenhain(dot)de>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Passing arguments to views
Date: 2006-02-03 13:33:23
Message-ID: DEB9CF0C-7880-44DB-ABC4-3DC5CCAA590E@bignerdranch.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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


In response to

Responses

pgsql-hackers by date

Next:From: Martijn van OosterhoutDate: 2006-02-03 13:34:25
Subject: Re: Multiple logical databases
Previous:From: Doug McNaughtDate: 2006-02-03 13:24:21
Subject: Re: Multiple logical databases

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