| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andrew Chernow <ac(at)esilo(dot)com> |
| Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: [PATCHES] libpq type system 0.9a |
| Date: | 2008-04-10 16:35:56 |
| Message-ID: | 2992.1207845356@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2008-04-10 16:45:15 | Re: Commit fest queue |
| Previous Message | Tom Lane | 2008-04-10 16:21:06 | Re: Commit fest queue |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2008-04-10 16:58:17 | Re: [PATCHES] libpq type system 0.9a |
| Previous Message | Andrew Chernow | 2008-04-10 15:16:37 | Re: [PATCHES] libpq type system 0.9a |