Re: streaming result sets: progress
От | snpe |
---|---|
Тема | Re: streaming result sets: progress |
Дата | |
Msg-id | 200211230951.34786.snpe@snpe.co.yu обсуждение исходный текст |
Ответ на | Re: streaming result sets: progress (Nic Ferrier <nferrier@tapsellferrier.co.uk>) |
Список | pgsql-jdbc |
On Friday 22 November 2002 11:55 pm, Nic Ferrier wrote: > Message-ID: <87of8h5fdc.fsf@pooh-sticks-bridge.tapsellferrier.co.uk> > Lines: 27 > MIME-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > --text follows this line-- > > snpe <snpe@snpe.co.yu> writes: > > On Friday 22 November 2002 07:16 pm, Nic Ferrier wrote: > > > snpe <snpe@snpe.co.yu> writes: > > > > Yet another sugestion : > > > > > > > > When make createStatement, we haven't to do fetch - command is same > > > > except begin; declare xxx cursor (I think that and begin will not be > > > > required soon) When we call first ResultSet.next (or like) we call > > > > fetch if don't rows in memory. It is way in another databases : > > > > execute is prepare and bind (without fetch) and then is fetch JDBC > > > > specification tell same - execute don't nothing with row > > > > > > JDBC spec doesn't require any particular behaviour... what we've got > > > kinda works. > > > > JDBC spec requires that after executeStatement there is nothing in > > ResultSet. > > No it doesn't. It requires that the result set is not positioned > until after the first call to next(). > > Postgresql's behaviour is quite legitimate. > Yes, it is legitime, but execute and fetch are separated command. There isn't good reason for doing fetch with execute - maybe user never call fetch. regards Haris Peco
В списке pgsql-jdbc по дате отправления: