Re: [PATCHES] libpq type system 0.9a

Tom Lane wrote:
> Andrew Chernow <ac@esilo.com> writes:
>> Recap: PQresultDup, PQresultSetFieldDesc and PQresultSetFieldValue.
>> We feel this approach, which we initially thought wouldn't work, is 
>> better than making pg_result public.
> 
> That doesn't seem to me to fit very well with libpq's internals ---
> in particular the PQresult struct is not designed to support dynamically
> adding columns, which retail PQresultSetFieldDesc() calls would seem to
> require, and it's definitely not designed to allow that to happen after
> you've begun to store data, which the apparent freedom to intermix
> PQresultSetFieldDesc and PQresultSetFieldValue calls would seem to
> imply.
> 
> Instead of PQresultSetFieldDesc, I think it might be better to provide a
> call that creates an empty (of data) PGresult with a specified tuple
> descriptor in one go.
> 
>             regards, tom lane
> 
> 

Are you against exposing PGresAttDesc?

PGresult *PQresultDup(  PGconn *conn,  PGresult *res,  int ntups,  int numAttributes,  PGresAttDesc *attDescs);

If you don't want to expose PGresAttDesc, then the only other solution 
would be to pass parallel arrays of attname[], tableid[], columnid[], 
etc...  Not the most friendly solution, but it would do the trick.

Recap: Use new PQresultDup, throw out setfielddesc and keep 
setfieldvalue the same.

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