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
