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/