On Thu, Apr 10, 2008 at 10:56 AM, Gregory Stark <[EMAIL PROTECTED]> wrote: > "Andrew Chernow" <[EMAIL PROTECTED]> 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
We see libpq types to be simply extending the api with more functions. We really only introduce new error handling with the PGparam struct that is following the same conventions that exist currently. The separation of libpqtypes out of libpq into a new library is an architectural change for organization purposes. We are not defining a new api or wrapping an existing one for new functionality (which is the same thing imo). With that in mind, libpq's error system is object based, not library based. Thee three objects that set errors are result, conn, (and now), param. In libpq terms there is no global error. (no errno, getlasterror, etc). So, if I understand you correctly, we see libpqtypes is an appendage in your terms...were you thinking along different lines? Consider that we don't reproduce all the things libpq offers, we share the same objects, etc. (In fact, we went though some acrobatics to introduce as little new behavior as possible). merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
