Re: [PATCHES] libpq type system 0.9a

Tom Lane wrote:
> Andrew Chernow <ac(at)esilo(dot)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/