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

Re: Passing arguments to views

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Chris Campbell <chris(at)bignerdranch(dot)com>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Tino Wildenhain <tino(at)wildenhain(dot)de>, Greg Stark <gsstark(at)mit(dot)edu>
Subject: Re: Passing arguments to views
Date: 2006-02-03 18:35:28
Message-ID: 200602031035.28782.josh@agliodbs.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom,

> As for the dependency issue, one man's bug is another man's feature.
> I think the fact that we don't track the internal dependencies of
> functions is not all bad.  We've certainly seen plenty of complaints
> about how you can't easily change tables that a view is depending on
> because the view dependencies block it...

I'd agree with this.   I write about 150,000 lines of function code a year, 
and if I had to rebuild all of the cascading functions every time I change 
a table they way I have to with views, it would probably add 20% to my 
overall application development time.

BTW, the other thing that we're still TODOing on SRFs (as far as I know) is 
finding ways to change the row estimate for an SRF.  It's still a flat 
1000 in the code, which can cause a lot of bad query plans.  I proposed a 
year ago that, as a first step, we allow the function owner to assign a 
static estimate variable to the function (i.e. "average rows returned = 
5').  This doesn't solve the whole problem of SRF estimates but it would 
be a significant step forwards in being able to use them in queries.

-- 
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco

In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2006-02-03 18:40:01
Subject: Re: [PATCHES] Fix for running from admin account on win32
Previous:From: Josh BerkusDate: 2006-02-03 18:20:30
Subject: Re: Multiple logical databases

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