On Thu, Apr 10, 2008 at 10:56 AM, Gregory Stark <stark@enterprisedb.com> wrote:
> "Andrew Chernow" <ac@esilo.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
We see libpq types to be simply extending the api with more functions.We really only introduce new error handling with
thePGparam 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
