shawn everett <[EMAIL PROTECTED]> writes:
> What I'd like to figure out is the best way to handle the say ~30
> calculations I'll need to do to generate the report. I could query the
> database and then do the calcuations in code via php, I could do them
> using one giant select statement, or I could possibly dump them all into a
> view provided I could find a way to pass a parameter to the view.
What do you consider "passing a parameter to the view" to be?
A view is a table --- one computed on-demand, rather than stored, but
still a table. You can use a SELECT ... WHERE to select a subset of
the rows in the table, and (with any luck ;-)) only those rows will
get computed.
If you can express your parameterization in terms of selecting some
rows and not others from a (possibly very large) virtual table, you're
all set.
There will probably be support in 7.2 or so for functions returning
recordsets as SELECT sources. A construct like
SELECT * FROM myfunc(42, 'foo');
would be a truly parameterized view, I think. But we can't do it today.
regards, tom lane
