Michael Fuhr wrote:
> ...
>
>Is there a reason you'd want to use a cursor instead of, say, a view?
>
>Are you just curious or is there a problem you're trying to solve?
>If I've misunderstood what you're asking then please elaborate.
>
I have previously thought this to be the most straightforward way to
solve certain problems, including functions that amount to
parameter-dependent views. If I want to join them against something not
anticipated in the first function, I have to either a) write another
function, copying the code in question, and adding the JOIN I want, or
b) write another function, call the first function, and execute an
astronomical number of little queries myself. Both bad options. Why
can't I SELECT FROM cursor JOIN some_table?
Similarly, but admittedly offtopic, I've also been irritated by the
ability to call scalar and set-returning functions as column expressions
(SELECT set_returning_function(t.a) FROM some_table? t) but not
multi-column functions, which can only be accessed via SELECT * FROM
multi_column_function('abc'). Why can't I SELECT
multi_column_function(t.a) FROM some_table t? The only solution I've
implemented is to write a SETOF function that encapsulates the previous
query, which adds needless complexity and is annoying when you have a
couple dozen queries you want to run. The other option is to make
multi_column_function actually return a single column in some way that
the application can split it apart again, but that's really ugly.
--Will Glynn
Freedom Healthcare
