Re: setFetchSize

Поиск
Список
Период
Сортировка
От fschmidt
Тема Re: setFetchSize
Дата
Msg-id 1319609361329-4938781.post@n5.nabble.com
обсуждение исходный текст
Ответ на Re: setFetchSize  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: setFetchSize  (Oliver Jowett <oliver@opencloud.com>)
Re: setFetchSize  (John R Pierce <pierce@hogranch.com>)
Re: setFetchSize  (Dave Cramer <pg@fastcrypt.com>)
Список pgsql-jdbc
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?


--
View this message in context: http://postgresql.1045698.n5.nabble.com/setFetchSize-tp4935215p4938781.html
Sent from the PostgreSQL - jdbc mailing list archive at Nabble.com.

В списке pgsql-jdbc по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: setFetchSize
Следующее
От: Oliver Jowett
Дата:
Сообщение: Re: setFetchSize