Prepared statements can have very visible effects apart from the speedup they provide (e.g. failure because of schema changes) It's not that these effects can't be worked around - they can be - but programmers can be surprised by these effects, which can cause difficult-to-diagnose issues.
The specific effect of "cached plan cannot change return type" can be solved by cooperation of backend and frontend (~driver) developers.
I really don't see how. As I said, an error is going to kill the ongoing transaction, how can this be solved without application logic? Unless you propose keeping track of all statements executed in the query and resend them?
I'm asking this out of genuine interest (I might be missing something), since I'm seriously considering implementing implicit query preparation in Npgsql.
I find that solving that kind of issues is more important than investing into "ParseBindExecDeallocateInOneGo" message.
I don't think it's solvable. But regardless, it's totally to invest in two things, I think it's totally legitimate to invest in implicit query preparation.
I hope you would forgive me if I just stop the discussion here.
Of course, no problem.
I find I'd better spent that time on just fixing pgbouncer issue rather than discussing if it is pgbouncer's or postgresql's issue.
The point is that it's not just a pgbouncer "bug". Connection pools like pgbouncer (there are others) usually send DISCARD ALL on connection close, which makes prepared statements useless for short-lived connection scenarios (since you have to reprepare). I don't know if that's changeable across pool implementations in general, and even if so, requires significant user understanding for tweaking the pool. So the general point is that the existence of pools is problematic for the argument "always prepare for recurring statements".
I'm sorry for being impolite if I was ever.
I don't think you were impolite, I personally learned a few things from the conversation and will probably implement opt-in implicit query preparation thanks to it.
