From: Tom Lane <tgl@sss.pgh.pa.us>
To: "Daniel Heath" <daniel@heath.cc>
cc: pgsql-novice@lists.postgresql.org
Subject: Re: Prepared statement invalidation
In-reply-to: <eae3cfcd-fe79-4516-b0ff-3872f2880943@www.fastmail.com>
References: <eae3cfcd-fe79-4516-b0ff-3872f2880943@www.fastmail.com>
Comments: In-reply-to "Daniel Heath" <daniel@heath.cc>
	message dated "Fri, 16 Apr 2021 10:09:38 +1000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3969077.1618532221.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 15 Apr 2021 20:17:01 -0400
Message-ID: <3969078.1618532221@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3969078.1618532221%40sss.pgh.pa.us>
Precedence: bulk

"Daniel Heath" <daniel@heath.cc> writes:
> I've found that when I add a new column, I sometimes get a spike of erro=
rs on the application side due to prepared statement query plans getting i=
nvalidated, causing transactions to rollback.
> The error is:
> ERROR: cached plan must not change result type =

> Is there a way to make postgres recalculate the query plan instead of fa=
iling the transaction when a new column is added?

No.  It'd be easy enough to remove that restriction on the server side,
but we're afraid that it would break applications, which probably aren't
expecting the result rowtype of a prepared query to be different from what
they were told (perhaps only milliseconds earlier).

I'd say the short answer is "don't use prepared queries, or if you do,
spell out the columns you want instead of saying SELECT *".

			regards, tom lane


> Thanks,
> Daniel Heath