| From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
|---|---|
| To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Manuel Kniep <m(dot)kniep(at)web(dot)de>, "fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp" <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
| Subject: | Re: PATCH: Batch/pipelining support for libpq |
| Date: | 2016-05-24 04:02:15 |
| Message-ID: | CAMsr+YGY7CO8+vWBqFfdYLqzrZSpcKHc-AVWSu25_++kek-Ecw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 24 May 2016 at 00:00, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> wrote:
>
> Did you consider the use of simple_list.c instead of introducing a new
> mimic as PGcommandQueueEntry? It would be cool avoiding adding new
> list emulations on frontends.
>
I'd have to extend simple_list to add a generic object version, like
struct my_list_elem
{
PG_SIMPLE_LIST_ATTRS;
mytype mycol;
myothertype myothercol;
}
Objections?
I could add a void* version that's a simple clone of the string version,
but having to malloc both a list cell and its contents separately is
annoying.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2016-05-24 04:28:40 | Re: PATCH: Batch/pipelining support for libpq |
| Previous Message | Peter Geoghegan | 2016-05-24 03:40:11 | Re: BTREE_BUILD_STATS build is broken |