Martijn van Oosterhout <kleptog@svana.org> writes:
>> The server has to prepare the query sometime. The v3 protocol just gives you
>> control over when that happens, but it doesn't force you to do it at any
>> particular time.
> Not really. All named prepares are planned straight away, all unnamed
> ones are planned at bind time. Therefore you cannot have more than one
> parsed-but-not-planned prepared query at a time. In a connection pool
> scenario there's no way to share such plans since you can't tell which
> query has been prepared. That's not forcing, but it's an asymmetry we
> could do with out.
Sure, but how much does it really matter? If you don't want the plan
saved for reuse, merely avoiding retransmission of the query text does
not seem like a major win. Having had time to think about it, I no
longer think the protocol design is a blocking bug for this problem
area. It's something we could improve when we are ready to design
protocol V4, but it does not seem in itself enough reason to make a
new protocol (with all the pain that entails).
regards, tom lane
