"Rather than executing a whole query at once, it is possible to set up a cursor that encapsulates the query, and then read the query result a few rows at a time. One reason for doing this is to avoid memory overrun when the result contains a large number of rows"
I'm assuming the memory overrun mentioned here is the memory of the client process connecting to postres. I think when a cursor ref is returned, say from a function, the query needs to be completed and the results must be ready for the cursor to move forward.
If that is the case, there must be a temporary table, presumably with one or more parameters to adjust its size, (location/tablespace?) etc..
Is this how cursors work internally? I can't imagine the complexity of managing cursor operations in anything other than extremely simple sql queries.
Any comments and/or pointers to documentation which explains this would be much appreciated.
