On Wed, Apr 9, 2008 at 11:17 AM, Andrew Chernow <ac@esilo.com> wrote:
> We can read args->get.result properties using PQfuncs with no problem. But
> we have no way of assign these values to our result 'r'.
By the way, our decision to 'create the result' when exposing arrays
and composites saved us from creating lot of interface code to access
these structures from user code...the result already gave us what we
needed. Just in case anybody missed it, the way arrays of composites
would be handled in libpq would be like this:
PGarray array;
PQgetf(res, 0, "%foo[]", 0, &array); // foo being a composite(a int, b float)
PQclear(res);
for (i = 0; i < PQntuples(array.res); i++)
{ a int; b float; PQgetf(array.res, i, "%int %float", 0, &a, 1, &b); [...]
}
PQclear(array.res);
In the getf call, the brackets tell libpq that this is an array and a
new result is created to present the array...one column for simple
array, multiple columns if the array is composite. This can be
recursed if the composite is nested. We support all the PGget*
functions for the newly created array, providing the OIDs of the
internal composite elements for example. This is, IMO, payoff of
doing all the work with the type handlers...we don't have to make a
special version of getf that operates over arrays for example.
The upshot of this is that, however separation occurs, the PGresult is
a first class citizen to the types library.
merlin
