> Yes, this was by choice: the example was developed with the command line interpreter in mind. That code was not supposed to be copied as a pattern. Anyway, I'll try to improve it or at least to make it clear.
Well, it is copied and it is fact of life. This is actually not Lua nor LuaSQL specific, people just do it and it is hard to blame them.
I did not want to imply that your code was bad, even though for use in production (in a system that runs Lua code repeatedly without exiting) it needs to be heavily modified to make sure resources are always released no matter what.
What I did want to say is the modification required to make that code "robust" would be an an exercise in careful and paranoid programming not unlike that practised in C with respect to dynamic memory allocation, which seems quite at odds with the nature of Lua.
> I think all LuaSQL drivers were carefully written to release the resources when the cursor reach the end of the result set.
That'a a pretty big assumption. Just recently I stumbled upon a big-name commercial ODBC driver that was ignoring the equivalent of env:close() and leaking multiple megabytes of memory as a result. That is definitely not a problem in LuaSQL, but it illustrates that an expectation of high quality might be mistaken.
> Unless there is an error during the for-loop, the resources will be release at the end regardless of the garbage collector.
"Unless there is an error" is precisely where the problem is; in practice, those non-memory resources are used when interacting with some "external" systems, when errors just happen, and the complexity of error handling that releases those resources is rarely anticipated by anyone. And when done "properly", it easily dominates the complexity of the "main" logic.
Cheers,
V.
