Re: [HACKERS] libpq Alternate Row Processor

Поиск
Список
Период
Сортировка
От Kyle Gearhart
Тема Re: [HACKERS] libpq Alternate Row Processor
Дата
Msg-id BLUPR14MB01624F0A61B6C3E863590DE0FA590@BLUPR14MB0162.namprd14.prod.outlook.com
обсуждение исходный текст
Ответ на Re: [HACKERS] libpq Alternate Row Processor  (Merlin Moncure <mmoncure@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Jim Nasby
Дата:
Сообщение: [HACKERS] Possible TODO: allow arbitrary expressions in event trigger WHEN
Следующее
От: Jeff Janes
Дата:
Сообщение: [HACKERS] renaming pg_resetxlog to pg_resetwal has broken pg_upgrade.