On 19 August 2016 at 22:16, Joshua Bay <joshuaba...@gmail.com> wrote:
> Oh I see.
> I just read more on use cases PgBouncer, but seems like it can't be used
> for my project.
> The reason is that I need to have my middleware to have full control over
> each transaction.
> That is it must be able to decide if it's going to commit or abort a
> single query (reason why libpq is used in the middleware), and it must be
> able to decide when to send back the result. Also it does things like load
> balancing with it's algorithm.
> So, what middleware does is (simplied, ignoring other details)
> 1. listens to query and does load balancing
> 2. execute query on behalf of client to server with libpq (does not have
> to be libpq).
> 3. serialize the result and send it back
> And the #3 is why I asked for ways to serialize PGresult (of libpq)
> Client app will deserialize the result and thus be able to interpret
> PGresult as if it used libpq itself.
Surely the app should just use libpq, and your middleware should be a proxy?
Like, say, PgPool-II?
Otherwise you'll have to extract all the results handling parts of libpq
into some smaller cut-down library and graft on
serialization/deserialization code. There's nothing built-in for that
,since the natural and logical serialization for query results is the
PostgreSQL wire protocol.
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services