Andrew Chernow wrote:
>
> For client_encoding and noticeHooks, the conn can be NULL. Previously,
> we copied this info from the source result when conn was NULL.
>
>
Looks like we don't need client_encoding. My guess is, in our use case
noticeHooks can probably be NULL for the created result, when makeresult
is not provided a conn.
> ....something like below>> res = PQmakeResult(...);> for(ntups)> {> PQresultAddEmptyTuple(res); // or
PQresultMakeEmptyTuple?> for(nfields)> PQresultSetFieldValue(res, tup_num, field_num, ....);> }>>
I think a better idea would be to make setfieldvalue more dynamic,
removing the need for PQresultAddEmptyTuple. Only allow tup_num to be
<= res->ntups. This will only allow adding one tuple at a time. The
other option would allow arbitray tup_nums to be passed in, like ntups
is 1 but the provided tup_num is 67. In this case, we would have to
back fill. It seems better to only grow by one tuple at a time. We can
get it working either way, we just prefer one tuple at a time allocation.
int PQresultSetFieldValue( PGresult *res, int tup_num, int field_num, char *value, int len)
{ if(!check_field_value(res, field_num)) return FALSE;
if(tup_num > res->ntups) // error, tup_num must be <= res->ntups
if(res->ntups >= res->tupArrSize) // grow res->tuples
if(tup_num == res->ntups && !res->tuples[tup_num]) // need to allocate tuples[tup_num]
// blah ... blah ...
}
New PQmakeResult prototype:
PQmakeResult( PGconn *conn, const char *cmdStatus, int binaryTuples, int numAttributes, PGresAttDesc *attDescs);
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/