From: | "Daniel Heath" <daniel(at)heath(dot)cc> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-novice(at)lists(dot)postgresql(dot)org |
Subject: | Re: Prepared statement invalidation |
Date: | 2021-04-16 06:16:45 |
Message-ID: | 42a0fd97-8cb2-4615-b9a8-698dc7c55962@www.fastmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-novice |
Is there a transaction isolation mode that would help with the specific case of adding a column to a table? EG to prevent a prepared statement from seeing the new schema?
Thanks,
Daniel Heath
On Fri, Apr 16, 2021, at 10:17 AM, Tom Lane wrote:
> "Daniel Heath" <daniel(at)heath(dot)cc> writes:
> > I've found that when I add a new column, I sometimes get a spike of errors on the application side due to prepared statement query plans getting invalidated, 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 failing 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
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Connah | 2021-04-18 12:08:41 | Dealing with multiple currencies with the money type? |
Previous Message | Tom Lane | 2021-04-16 00:17:01 | Re: Prepared statement invalidation |