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/