> 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 ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
