Re: [PATCHES] libpq type system 0.9a - Mailing list pgsql-hackers

From Andrew Chernow
Subject Re: [PATCHES] libpq type system 0.9a
Date
Msg-id 47FCDDF6.2020002@esilo.com
Whole thread Raw
In response to Re: [PATCHES] libpq type system 0.9a  (Andrew Chernow <ac@esilo.com>)
Responses Re: [PATCHES] libpq type system 0.9a  ("Merlin Moncure" <mmoncure@gmail.com>)
Re: [PATCHES] libpq type system 0.9a  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Andrew Chernow wrote:
>>
>> What parts of PGconn/PGresult do you need to touch that aren't exposed
>> already?

Don't need direct access to PGconn at all.

result:
null_field
tupArrSize
client_encoding (need a PGconn for this which might be dead)
pqSetResultError
pqResultAlloc
pqResultStrdup

Also, we basically need write access to every member inside a result 
object ... since we create our own for arrays and composites by copying 
the standard result members over.

/* taken from dupresult inside handlers/utils.c */

PGresult *r = (PGresult *)malloc(sizeof(PGresult));
memset(r, 0, sizeof(PGresult));

/* copy some data from source result */
r->binary          = args->get.result->binary;
r->resultStatus    = args->get.result->resultStatus;
r->noticeHooks     = args->get.result->noticeHooks;
r->client_encoding = args->get.result->client_encoding;
strcpy(r->cmdStatus, args->get.result->cmdStatus);

[snip...]

We can read args->get.result properties using PQfuncs with no problem. 
But we have no way of assign these values to our result 'r'.

-- 
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Commit fest queue
Next
From: Alvaro Herrera
Date:
Subject: Re: Calling GSoc Mentors