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/
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
