Heikki Linnakangas <hlinnakangas@vmware.com> writes:
> While looking at the memory leaks in ecpg that Coverity warned about and
> Michael just fixed, I started wondering if the code is ever used.
Michael Meskes would be the authority on that question, so I've cc'd
him to make sure he notices this thread ...
> The leaks were in the code that takes a host variable, and converts it
> into a string for sending to the server as a query parameter. In
> particular, it was in code that deals with arrays. However, the fine
> manual says:
>> SQL-level arrays are not directly supported in ECPG. It is not
>> possible to simply map an SQL array into a C array host variable.
>> This will result in undefined behavior. Some workarounds exist,
>> however.
> That very clearly says that the code that was fixed is not actually
> supported.
It seems quite possible to me that this manual text is out of date.
> We do have a test case, 'arrays', that tests the code, but it only tests
> integer arrays. The leaks were in 'interval', 'timestamp', and 'numeric'
> arrays. And it turns out that there are two bugs there:
> 1. In timestamp, interval, and date, the array offset is calculated
> incorrectly:
> str = quote_postgres(PGTYPESinterval_to_asc((interval *) ((var +
> var->offset * element)->value)), quote, lineno);
> That "var + var->offset * element" has C datatype "struct variable *",
> not "char *" as the code assumes, so the calculated offset is wrong,
> leading to bogus parameters or segfault
> 2. The constructed array looks like this (for timestamp):
> array [2005-06-23 11:22:33,2004-06-23 11:22:33]
> That's bogus. It's sent as a query parameter, not embedded into an SQL
> string, so the syntax should be '{...}'.
> It would be nice to fix these, and add a test case to cover all kinds of
> arrays. Although technically, it works as advertised, because the manual
> says that it will result in "undefined behaviour".
regards, tom lane
