QR_Destructor() calls QR_close_result(), which free's all the resources
associated with the result set. It also calls QR_Destructor() on the
next result set in the chain. In other words, when you call
QR_Destructor() on the first result, it recurses to free all the chained
results.
That recursion is a problem. A chained result set occurs at least if you
use array binding; there is one chained result for each element in the
parameter array. ODBC applications typically use parameter arrays to
bulk insert data, in which case the parameter array can be very large.
I bumped into this in an application that bound over 10000 parameters in
a statement. That works otherwise, but 10000-level deep recursion
sometimes causes the application to run out of stack space. The funny
thing is that the recursion happens when the statement is free'd; other
operations don't recurse.
It's pretty obvious that QR_destructor/QR_close_result() should iterate,
not recurse, through the chained results. Patch attached. Aside from
avoiding running out of stack space, this speeds up freeing the
statement considerably.
I've also pushed this to my github repository at
https://github.com/hlinnaka/psqlodbc. I also added a test case for array
binding parameters to the master-with-testcases branch in the same
repository.
- Heikki