Dave Cramer <davecramer@postgres.rocks> writes: > This is really an issue that needs to be solved in the backend. The error > is coming from PostgreSQL and what should happen is that when you alter a > table that a server prepared statement relies on the backend should send a > message to tell us that all of the prepared statements that rely on are now > invalid and we can reprepare them.
This is something that can't change without a wire protocol change. There is nothing in the protocol that allows the backend to send out a message like "oh, that Describe I sent you awhile back? It might be a lie now" at random times.
I agree, but it's a known issue. I'm just pointing that it would be nice to have.
We'd have to figure out the details.
Also, what do you want to do about race conditions --- that is, what if you fire off an Execute only to find that one of those messages was already in flight to you?
A non-racy way to handle it might be for Bind/Execute to refuse to run the query if its output has changed since the last Describe, which we could check after acquiring table locks during Bind. But we'd want to define "refuse" in a way that doesn't abort the transaction, and that's a concept that doesn't exist in the protocol at all.
This actually sounds like the best option as we wouldn't have to fire off a message, just refuse to run the Execute in a way that doesn't abort the transaction.
