libpq object hooks -- needs copy result - Mailing list pgsql-hackers

From Merlin Moncure
Subject libpq object hooks -- needs copy result
Date
Msg-id b42b73150804240704g312286c3pd509bf39a374c34a@mail.gmail.com
Whole thread Raw
Responses Re: libpq object hooks -- needs copy result  (Andrew Chernow <ac@esilo.com>)
List pgsql-hackers
We are trying to clean up the object hooks patch (on the libpq side)
in time for the May commit fest.  The last version we posted is here:
http://www.nabble.com/libpq-object-hooks-patch-to16707707.html

Everything for the most part works ok but there is a problem with the
function 'PQmakeResult' which essentially takes a PGconn and a list of
attributes.

The PGconn here is extra baggage: we really need a 'src' result (we
are creating a result from a result with customization).  We do need
to copy some information out of the PGresult.

With an eye towards sideband utility, we are suggesting:
PQcopyResult(PGresult *dest, const PGresult *src, int numAttributes,
PGresAttDesc *attDescs, int options);

One nice thing about that is the following functions are no longer
required.  We needed them to pull some of the private information out
of the result...since the deep copy happens inside libpq they are no
longer necessary.
PQobjectHooks
PQresultObjectHooks

The 'options' argument allows customizing the behavior of the copy
with some flags, for example to copy (or not), tuples, notice hooks,
object hooks, etc, or to use the src PGresult attDescs or to take the
supplied list.

PQcopyResult appears to be the only way the hooks can really work.  At
the time it is called, the originating PGconn could be destroyed and
provides no useful information to the newly created result.  This will
also affect the hooks slightly but the ability to 'copy' a result is
key.

With the change, the hook approach appears to work quite well with
libpq types.  If this is acceptable, we will have a new hook patch up
shortly.

merlin


pgsql-hackers by date:

Previous
From: Gregory Stark
Date:
Subject: Re: Index AM change proposals, redux
Next
From: Fujii Masao
Date:
Subject: Avoiding a needless failure of PITR