Re: Add function to release an allocated SQLDA - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Add function to release an allocated SQLDA
Date
Msg-id CAEepm=0O5sYhF1Oc0QDdKA7z29Cj0cBkBTDnFWnH_q2Caew8Sg@mail.gmail.com
Whole thread Raw
In response to RE: Add function to release an allocated SQLDA  ("Kato, Sho" <kato-sho@jp.fujitsu.com>)
Responses Re: Add function to release an allocated SQLDA  (Dmitry Dolgov <9erthalion6@gmail.com>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Negotiating the SCRAM channel binding type
Next
From: Alvaro Herrera
Date:
Subject: Re: _isnan() on Windows