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
