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 47FD6530.90700@esilo.com
Whole thread Raw
In response to Re: [PATCHES] libpq type system 0.9a  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCHES] libpq type system 0.9a  (Andrew Chernow <ac@esilo.com>)
List pgsql-hackers
Tom Lane wrote:
> 
> Perhaps we could do a partial exposure, where the exported struct
> declaration contains "public" fields and there are some "private" ones
> after that.  
> 
> 

I have another idea.  It would remove a boat load of members that would need to 
be exposed (may remove them all).

Can we make a variant of PQmakeEmptyPGresult?  Maybe something like this:

PGresult *PQdupPGresult( // maybe not the best name?  PGconn *conn,  PGresult *source,  int numAttributes,  int
ntups);

This starts off by calling PQmakeEmptyPGresult and then copying the below 
members from the provided 'source' result argument.
- ExecStatusType resultStatus;
- char cmdStatus[CMDSTATUS_LEN];
- int binary;
- PGNoticeHooks noticeHooks;
- int client_encoding;

It would then preallocate attDescs and tuples which would also set 
numAttributes, ntups & tupArrSize.  attdescs and tuples are not duplicated, only 
allocated based on the 'numAttributes' and 'ntups' arguments.  Now libpqtypes 
only needs direct access to attDescs and tuples, for when it loops array 
elements or composite fields and copies stuff from the source result.

Any interest in this direction?  I am still thinking about how to abstract 
attDesc and tuples, I think it would require more API calls as well.

curBlock, curOffset and spaceLeft were never copied (intialized to zero).  We 
don't touch these.

-- 
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: Andrew Chernow
Date:
Subject: Re: [PATCHES] libpq type system 0.9a