On Wed, Oct 26, 2011 at 2:09 AM, fschmidt <fschmidt@gmail.com> wrote:
> Okay I see the documentation saying portals die at the end of a transaction,
> here:
>
> http://developer.postgresql.org/pgdocs/postgres/protocol-flow.html#PROTOCOL-FLOW-EXT-QUERY
>
> But looking at the JDBC code, the main use I see of portals is for
> setFetchSize(). And setFetchSize() is badly crippled in its current
> implementation. Is there any fundamental reason that portals can't be made
> to survive commits, like cursors WITH HOLD? This would result in a
> reasonable implementation of setFetchSize().
>
> For now I have given up on setFetchSize() as useless for my application, and
> I use "select ... order by something-unique limit fetch-size offset
> how-much-has-been-read". This is a bad hack. I would much rather use a
> functional implementation of setFetchSize(). Is there any chance I will get
> one?
>
There is little hope that you will get what you want. I'm not even
sure I think it's a good idea as cursor with hold consumes resources
on the server which multiplied by an unknown number of connections
might end up being significant.
FWIW the JDBC docs do not imply any contract for setFetchSize.
Dave Cramer
dave.cramer(at)credativ(dot)ca
http://www.credativ.ca