Re: [PATCHES] libpq type system 0.9a

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/