Invalidate prepared statements on ALTER TYPE

Ok, got clarification offline from Bret. The issue is the client can fail just at BIND so it never gets to the point of allowing the EXECUTE to happen that would return UNPREPARED and might fix things.

If the server throws a “UNPREPARED” response, because the server side cache got cleared, how can there be no “re-prepare”? Maybe I’m confused with how this works, but I thought the client needs to do a prepare again?

The issue I assumed was that when the re-prepare happens the client currently doesn’t refresh it’s saved metadata, but re-uses the existing cached data? So rather than re-using the existing it should cache the result of the PREPARE call it just did?

If I’m understanding you right (and it’s entirely possible I’m not) @Jeremiah Jordan there’s a non-trivial isue with your suggestion. Because we’re using the client-side cached statement there is no re-prepare, so presumably the only way to leave this to the server would be… to not use the client-side cache at all and (in essence) always re-prepare.

Please set me straight if I did misunderstand.

The server side should be invalidating the prepared statement on its side such that it would need to be re-prepared. Rather than clearing things out when the alter comes in, maybe clearing on re-prepare would be easier?

The problem here is that the driver can be notified of changes in the UDT structure; the sample code included as part of this ticket makes that very clear. But the driver has no way to determine whether an individual UDT change affects any currently cached prepared statement without walking through each of them and determining whether the cached value is affected by a given UDT change. The keys for this cache are PreparedRequests and at the point we don’t really have access to column-level metadata… so it’s not immediately clear there’s enough context here to even make sure a comparison.

We probably could enhance the type being cached to include such info and attempt some kind of validation on schema changes… but that’s potentially a much more intrusive change.