Andrew Chernow wrote:
>
> /* Only for results returned by PQresultDup. This
> * will append a new tuple to res. A PGresAttValue
> * is allocated and put at index 'res->ntups'. This
> * is similar to pqAddTuple except that the tuples
> * table has been pre-allocated. In our case, ntups
> * and numAttributes are known when calling resultDup.
> */
> int PQresultAddTuple(
> PGresult *res,
> char *value,
> int len);
>
PQresultAddTuple is not quite correct. The below is its replacement:
int PQresultSetFieldValue( PGresult *res, int tup_num, int field_num, char *value, int len)
Recap: PQresultDup, PQresultSetFieldDesc and PQresultSetFieldValue.
We feel this approach, which we initially thought wouldn't work, is
better than making pg_result public.
These functions could be useful outside of pqtypes, providing a way of
filtering/modifying a result object ... consider:
PGresult *execit(conn, stmt)
{ res = PQexec(conn, stmt); if(some_app_cond_is_true) { newres = PQresultDup(); // ... customize tups and
fields //PQresultSetFieldDesc and PQresultSetFieldValue PQclear(res); res = newres; } return res;
}
// res could be custom built
res = execit(conn, stmt);
PQclear(res);
This is not an everyday need, but I'm sure it could provide some niche
app functionality currently unavailable. Possibly useful to libpq
wrapper APIs. Either way, it works great for pqtypes and avoids
exposing pg_result.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/