Bruce Momjian <bruce@momjian.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.
Frankly speaking, it is not clear what this change buys.
Are you sure v3 cannot be tuned to reach comparable performance?
I do not like very much having a variety of "query modes".
For instance, when working with logical replication, extended queries are not supported over the wire, that complicates client.
If adding one more "execute flavor" the things would get only worse, not better.
Reusing parse state does indeed improve the performance in real-life applications, so I would wonder if we can make current "extended" query faster rather than implementing yet another protocol.
So while the request itself would definitely make sense if we had no "v2/v3" protocols at all, however as we do have v2 and v3, it adding "PQexecParams's feature set" looks not that important.
