On Tue, Jun 19, 2018 at 9:11 PM, Kato, Sho <kato-sho@jp.fujitsu.com> wrote:
>>This is not clear to me. ECPGfreeSQLDA() releases a whole chain, but
>>free() only releases a single SQLDA(), so they are obviously not interchangeable. When exactly should a user prefer
oneover the other?
>
> If an application use FETCH ALL to get the result set at once, a user should use ECPGfreeSQLDA().
> Because the user does not know that the SQLDA holds the result set in the chain.
> If it does not release it will remain leaked.
>
> Considering the use of people who know the structure of SQLDA, I described the releasing method using free () in the
document.
I wonder how other ESQL/C implementations deal with this stuff. The
DB2 SQLDA struct[1] doesn't have desc_next. The Informix one[2] does,
but I'm not entirely sure what it's for since Informix apparently
doesn't support EXEC SQL FETCH ALL. The Informix manual also lists a
function SqlFreeMem() that is needed on Windows for the same reason we
need a new function[3]. I don't think there is anyone left who cares
about compatibility with Informix so (unless there is some guidance
from the spec here) I think your proposed name ECPGfreeSQLDA() is OK.
test/sql/sqlda.pgc includes a bit where SQLDA objects are still freed
with free(). That's because the loop does extra processing with each
SQLA:
while (outp_sqlda1)
{
....blah blah...
outp_sqlda1 = outp_sqlda1->desc_next;
free(ptr);
}
To allow that type of usage, we would need two new functions:
ECPGfreeSQLDA() to free just one, and ECPGfreeAllSQLDA() to free the
whole chain. The minimum thing to back-patch would be a
EDPGfreeSQLDA() function to free just one, since that fixes a
potential bug for Window users (the same reason we back-patched
4c8156d87108fa1f245bee13775e76819cd46a90). Then ECPGfreeAllSQLDA()
(or better name) could be a separate patch to discuss for PG 12. Does
that make sense?
sqlda.c:
+void
+ECPGfreeSQLDA_informix(struct sqlda_compat *sqlda_ptr)
+{
ecpglib.h:
+void ECPGfreeSQLDA_compat(struct sqlda_compat *);
I think these function names were supposed to match?
[1] https://www.ibm.com/support/knowledgecenter/en/SSEPGG_9.7.0/com.ibm.db2.luw.apdv.api.doc/doc/r0001751.html
[2] https://www.ibm.com/support/knowledgecenter/en/SSGU8G_12.1.0/com.ibm.esqlc.doc/ids_esqlc_0656.htm
[3] https://www.ibm.com/support/knowledgecenter/en/SSGU8G_11.50.0/com.ibm.esqlc.doc/xbsql1007134.htm
--
Thomas Munro
http://www.enterprisedb.com