Re: Support prepared statement invalidation when result types change

@Euler thanks for the review. I addressed the feedback.

On Fri, 15 Sept 2023 at 01:41, Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com> wrote:
> What if a client has *cached* an old version of RowDescription
> and the server changed it to something new and sent resultdata
> with the new RowDescription. Will the client still be able to work
> expectly?

It depends a bit on the exact change. For instance a column being
added to the end of the resultdata shouldn't be a problem. And that is
actually quite a common case for this issue:
1. PREPARE p as (SELECT * FROM t);
2. ALTER TABLE t ADD COLUMN ...
3. EXECUTE p

But type changes of existing columns might cause issues when the
RowDescription is cached. But such changes also cause issues now.
Currently the prepared statement becomes unusable when this happens
(returning errors every time). With this patch it's at least possible
to have prepared statements continue working in many cases.
Furthermore caching RowDescription is also not super useful, most
clients request it every time because it does not require an extra
round trip, so there's almost no overhead in requesting it.

Clients caching ParameterDescription seems more useful because
fetching the parameter types does require an extra round trip. So
caching it could cause errors with 0003. But right now if the argument
types need to change it gives an error every time when executing the
prepared statement. So I believe 0003 is still an improvement over the
status quo, because there are many cases where the client knows that
the types might have changed and it thus needs to re-fetch the
ParameterDescription: the most common case is changing the
search_path. And there's also cases where even a cached
ParamaterDescription will work fine: e.g. the type is changed but the
encoding stays the same (e.g. drop + create an enum, or text/varchar,
or the text encoding of int and bigint)