Re: [HACKERS] libpq Alternate Row Processor - Mailing list pgsql-hackers

From Kyle Gearhart
Subject Re: [HACKERS] libpq Alternate Row Processor
Date
Msg-id BLUPR14MB01624F0A61B6C3E863590DE0FA590@BLUPR14MB0162.namprd14.prod.outlook.com
Whole thread Raw
In response to Re: [HACKERS] libpq Alternate Row Processor  (Merlin Moncure <mmoncure@gmail.com>)
List pgsql-hackers
On Mon, Feb 13, 2017 Merlin Moncure wrote:
>A barebones callback mode ISTM is a complete departure from the classic PGresult interface.  This code is pretty
unpleasantIMO:
 
acct->abalance = *((int*)PQgetvalue(res, 0, i)); abalance = 
acct->__bswap_32(acct->abalance);

> Your code is faster but foists a lot of the work on the user, so it's kind of cheating in a way (although very
carefullywritten applications might be able to benefit).
 

The bit you call out above is for single row mode.  Binary mode is a slippery slope, with or without the proposed
callback.

Let's remember that one of the biggest, often overlooked, gains when using an ORM is that it abstracts all this mess
away. The goal here is to prevent all the ORM/framework folks from having to implement protocol.  Otherwise they get to
waiton libpq to copy from the socket to the PGconn buffer to the PGresult structure to their buffers.  The callback
keepsthe slowest guy on the team...on the bench. 
 


Kyle Gearhart


pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: [HACKERS] Possible TODO: allow arbitrary expressions in event trigger WHEN
Next
From: Jeff Janes
Date:
Subject: [HACKERS] renaming pg_resetxlog to pg_resetwal has broken pg_upgrade.