Re: [PATCHES] libpq type system 0.9a

Поиск
Список
Период
Сортировка
От Andrew Chernow
Тема Re: [PATCHES] libpq type system 0.9a
Дата
Msg-id 47FD6530.90700@esilo.com
обсуждение исходный текст
Ответ на Re: [PATCHES] libpq type system 0.9a  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [PATCHES] libpq type system 0.9a  (Andrew Chernow <ac@esilo.com>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Commit fest queue
Следующее
От: Andrew Chernow
Дата:
Сообщение: Re: [PATCHES] libpq type system 0.9a