Re: CommandStatus from insert returning when using a portal.
От | Chapman Flack |
---|---|
Тема | Re: CommandStatus from insert returning when using a portal. |
Дата | |
Msg-id | 68b15341f43807f25cc860ea188d420b@anastigmatix.net обсуждение исходный текст |
Ответ на | Re: CommandStatus from insert returning when using a portal. (Dave Cramer <davecramer@gmail.com>) |
Ответы |
Re: CommandStatus from insert returning when using a portal.
|
Список | pgsql-hackers |
On 2023-07-14 17:02, Dave Cramer wrote: > The fly in the ointment here is when they setFetchSize and we decide to > use a Portal under the covers. A person might language-lawyer about whether setFetchSize even applies to the kind of thing done with executeUpdate. Hmm ... the apidoc for setFetchSize says "Gives the JDBC driver a hint as to the number of rows that should be fetched from the database when more rows are needed for ResultSet objects generated by this Statement." So ... it appears to apply to any "ResultSet objects generated by this Statement", and getGeneratedKeys returns a ResultSet, so maybe setFetchSize should apply to it. OTOH, setFetchSize has @since 1.2, and getGeneratedKeys @since 1.4. At the time setFetchSize was born, the only way you could get a ResultSet was from the kind of thing you'd use executeQuery for. So when getGeneratedKeys was later added, a way of getting a ResultSet after an executeUpdate, did they consciously intend it to come under the jurisdiction of existing apidoc that concerned the fetch size of a ResultSet you wanted from executeQuery? Full employment for language lawyers. Moreover, the apidoc does say the fetch size is "a hint", and also that it applies "when more rows are needed" from the ResultSet. So it's technically not a misbehavior to disregard the hint, and you're not even disregarding the hint if you fetch all the rows at once, because then more rows can't be needed. :) Regards, -Chap
В списке pgsql-hackers по дате отправления: