Skip site navigation (1) Skip section navigation (2)

libpq object hooks -- needs copy result

From: "Merlin Moncure" <mmoncure(at)gmail(dot)com>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Cc: "Andrew Chernow" <ac(at)esilo(dot)com>
Subject: libpq object hooks -- needs copy result
Date: 2008-04-24 14:04:43
Message-ID: b42b73150804240704g312286c3pd509bf39a374c34a@mail.gmail.com (view raw or flat)
Thread:
Lists: 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

Responses

pgsql-hackers by date

Next:From: Fujii MasaoDate: 2008-04-24 14:25:00
Subject: Avoiding a needless failure of PITR
Previous:From: Gregory StarkDate: 2008-04-24 12:13:02
Subject: Re: Index AM change proposals, redux

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group