ecpg array support, or lack thereof - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject ecpg array support, or lack thereof
Date
Msg-id 54D21C91.30906@vmware.com
Whole thread Raw
Responses Re: ecpg array support, or lack thereof  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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.

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.

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".

- Heikki



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: pg_dump's aborted transactions
Next
From: Andres Freund
Date:
Subject: Re: Getting rid of wal_level=archive and default to hot_standby + wal_senders