> If this will be used interactively, it would be nice to have both. That
> way if you're running a bunch of cursor fetches, you can just do one
> \set, but if you only want to run one or a few you can use \gc and not
> mess around with \set. But I don't know how common interactive usage
> will be. Presumably code can easily be taught to do either, though \set
> would probably be less invasive to older code that someone wants to
> change.
I don't know if having both is really that desirable. In particular,
as Peter pointed out, \gc is not possible because it means \g outputting
to file 'c' in the current version of psql.
> Another thought (which probably applies more to \set than \gc): if you
> could set a threshold of how many rows the planner is estimating before
> automatically switching to a cursor, that would simplify things.
> Interactively, you could just let psql/PostgreSQL decide which was best
> for each query. Same is true in code, though it probably matters more
> for existing code than new code.
Right now, this would be very hard, because the existing output code
cannot readily be adapted to using cursors. My patch does fetching and
output in a new code path that is very simple, but doesn't do all the
nice formatting for human readability. So moving seamlessly between the
two behind the scenes is not possible, least refactoring the whole
output code of psql.
Tom Lane mentioned the solution at the root of all this eventually might
be a new version of libpq that does large fetches in chunks on its own.
But, we're talking > 8.2.0 then...
Bye :)
Chris.
--
Chris Mair
http://www.1006.org
