I'm sorry, we are discussing technical details with no real-life use case to cover that.
I do not want to suck time for no reason. Please accept my sincere apologies for not asking the real-life case earlier.
Shay, can you come up with a real-life use case when those "I claim the statement will be used only once" is would indeed improve performance?
Or, to put it in another way: "do you have a real-life case when simple protocol is faster than extended protocol with statement reuse"?
I do have a couple of java applications and it turns out there's a huge win of reusing server-prepared statements.
There's a problem that "generic plan after 5th execution might be much worse than a specific one", however those statements are not often and I just put hints to the SQL (limit 0, +0, CTE, those kind of things).
I do not accept this idea that retroactively defining special semantics for certain statement names is not a protocol break.
Sir, any new SQL keyword is what you call a "retroactively defining special semantics".
It's obvious that very little current clients do use named server-prepared statements.
Statement names are not something that is provided by the end-user in a web page, so it is not a rocket science to come up with a statement name that is both short and "never ever used in the wild".
And even if it were true, why is it that this way would safely pass through existing releases of pgbouncer when other ways would not? Either pgbouncer needs to understand what it's passing through, or it doesn't.
Once again: exiting pgbouncer versions know how to parse Parse/Bind/Exec/Deallocate messages, so if we bless some well-defined statement name with a semantics that "it is forbidden to reuse that name for multiple executions in a row", then that is completely transparent for pgbouncer. Pgbouncer would just think that "the application is dumb since it reparses the same statement again and againt", but it would work just fine.
On contrary, if a new statement name is added, then pgbouncer would fail to understand the new message.
