We have a supplier who uses it to distribute daily updates to their (large) product catalog. It helps that most of the mutations are to specific fields like availability and price, while EAN/GTIN etc tend to be stable. Deletions are trivial as well.
I would expect a major Postgres version upgrade to hit these conditions, so the OP problem would still occur. Nevertheless, thanks for the pointer - I had mostly forgotten about this possibility.
I'd like to correct myself on this point, it seems that if Postgres picks custom_plan over generic_plan it will always re-plan (that is what custom_plan is, it takes the prepared statement parameters into account while generic_plan always uses the same plan regardless of the parameters). So it's a toss up whether Postgres will actually lock in the static query plan over the dynamic query plan.
