Shay>As I said, an error is going to kill the ongoing transaction, how can this be solved without application logic?
1) At least, some well-defined error code should be created for that kind of matter.
As far as I can remember, performance overheads are close to zero (no extra roundtrips to create a safepoint)
3) Backend could somehow invalidate prepared statements, and notify clients accordingly. Note: the problem is hard in a generic case, however it might be not that hard if we fix well-known often-used cases like "a column is added". That however, would add memory overheads to store additional maps like "table_oid -> statement_names[]"
4) Other. For instance, new message flow so frontend and backend could re-negotiate "binary vs text formats for the new resulting type". Or "ValidatePreparedStatement" message that would just validate the statement and avoid killing the transaction if the statement is invalid. Or whatever else there can be invented.
Shay>So the general point is that the existence of pools is problematic for the argument "always prepare for recurring statements".
So what?
Don't use pools that issue "discard all" or configure them accordingly. That's it.
In Java world, no wildly used pool defaults to "discard everything" strategy.
Please stop saying "pgbouncer" as its issue is confirmed, and pgbouncer developers did acknowledge they would prefer to solve "prepared statement issue" right inside pgbouncer without any cooperation from driver developers.
Do you mean in C# world major connection pools default to "discard all" setup? That sounds strange to me.
Vladimir