| From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
|---|---|
| To: | "Andrew Chernow" <ac(at)esilo(dot)com> |
| Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "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 14:56:49 |
| Message-ID: | 87zls1u5am.fsf@oxford.xeocode.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches |
"Andrew Chernow" <ac(at)esilo(dot)com> writes:
> How would the caller of getvalues know whether the error was generated by a
> libpqtypes API call or by a libpq API call (like PQgetvalue)? PQgetf should
> behave exactely as PQgetvalue does, in regards to errors.
Hm. Well I was thinking of errors from database operations rather than things
like PQgetvalue.
I suppose we have to decide whether pqtypes is a "wrapper" around libpq in
which case your functions would have to take the libpq error and copy it into
your error state or an additional set of functions which are really part of
appendage of libpq
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's 24x7 Postgres support!
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2008-04-10 14:58:51 | Re: [HACKERS] [SQL] pl/PgSQL, variable names in NEW |
| Previous Message | Andrew Dunstan | 2008-04-10 14:56:31 | Re: [HACKERS] [SQL] pl/PgSQL, variable names in NEW |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Merlin Moncure | 2008-04-10 15:14:45 | Re: [PATCHES] libpq type system 0.9a |
| Previous Message | Martijn van Oosterhout | 2008-04-10 14:53:28 | Re: MSVC build broken with perl 5.10 |