| From: | Bruce Momjian <bruce(at)momjian(dot)us> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Greg Stark <stark(at)mit(dot)edu>, Shay Rojansky <roji(at)roji(dot)org>, Tatsuo Ishii <ishii(at)postgresql(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Slowness of extended protocol |
| Date: | 2016-08-03 23:35:15 |
| Message-ID: | 20160803233515.GB1702@momjian.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Aug 3, 2016 at 10:02:39AM -0400, Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > On Sun, Jul 31, 2016 at 05:57:12PM -0400, Tom Lane wrote:
> >> In hindsight it seems clear that what a lot of apps want out of extended
> >> protocol is only the ability to send parameter values out-of-line instead
> >> of having to quote/escape them into SQL literals. Maybe an idea for the
> >> fabled V4 protocol update is some compromise query type that corresponds
> >> precisely to PQexecParams's feature set: you can send parameter values
> >> out-of-line, and you can specify text or binary results, but there's no
> >> notion of any persistent state being created and no feedback about
> >> parameter data types.
>
> > Do you want this on the TODO list?
>
> I didn't hear anyone say it was a silly idea, so sure.
Done:
Create a more efficient way to handle out-of-line parameters
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2016-08-03 23:54:50 | Re: regression test for extended query protocol |
| Previous Message | Bruce Momjian | 2016-08-03 23:28:52 | Re: Lossy Index Tuple Enhancement (LITE) |