Re: libpq Alternate Row Processor

From: Kyle Gearhart <kyle(dot)gearhart(at)indigohill(dot)io>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: libpq Alternate Row Processor
Date: 2017-02-13 22:50:08
Message-ID: BLUPR14MB01624F0A61B6C3E863590DE0FA590@BLUPR14MB0162.namprd14.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 unpleasant IMO:
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 carefully written 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 wait on libpq to copy from the socket to the PGconn buffer to the PGresult structure to their buffers. The callback keeps the slowest guy on the team...on the bench.

Kyle Gearhart

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Janes 2017-02-14 00:09:41 renaming pg_resetxlog to pg_resetwal has broken pg_upgrade.
Previous Message Jim Nasby 2017-02-13 22:45:31 Possible TODO: allow arbitrary expressions in event trigger WHEN