25.02.2017 11:47, Mark Rotteveel wrote: > On 25-2-2017 09:31, Vlad Khorsun wrote: >> If think a bit deeper, it will be clear that there is no other way as >> send big result sets >> in parts over the wire. Also, why don't you ask if they fully fetch >> resultset at the server side ? >> >> What you offer is very hard to use in practice as nobody able to explain >> why statement was >> cancelled at this moment and it is impossible to predict moment when timeout >> should fire. >> >> Well, as we can't agree i offer to choose one of the following : >> 1. Leave it as is >> 2. Completely exclude fetches from timeout scope >> 3. Remove the whole feature > > Would it be possible to apply the timeout to execute + first fetch?
Yes. I'm afraid to ask - why... > Or apply the timeout to the execute only, and separately for each fetch > (where the fetch call would/could include a timeout value as well)? Here you again catched by the same trap - there is no direct relation between API call fetch() and network packet op_fetch. It is unknown and not predictable. And it will work absolutely differently for network and embedded cases. And it will be different even for INET\XNET cases. Users will be "happy". If you need to set timeout on network wait, call it this way, ok. But don't mix it with statemenet execution timeout. And be ready that only reliable way to handle network timeout is to abort whole connection. While statement execution timeouts is handled in a much less *harsh* way. Regards, Vlad ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
