Tom Lane wrote:
Andrew Chernow <[EMAIL PROTECTED]> 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/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
