Re: Support prepared statement invalidation when result types change - Mailing list pgsql-hackers

From Jelte Fennema
Subject Re: Support prepared statement invalidation when result types change
Date
Msg-id CAGECzQT0Hf6_6m_KhKDvmy2Kanxm543nhq80t_O+_C1e=0WwLg@mail.gmail.com
Whole thread Raw
In response to Re: Support prepared statement invalidation when result types change  (jian he <jian.universality@gmail.com>)
Responses Re: Support prepared statement invalidation when result types change
List pgsql-hackers
On Tue, 29 Aug 2023 at 11:29, jian he <jian.universality@gmail.com> wrote:
> regression=# CREATE TEMP TABLE pcachetest AS SELECT * FROM int8_tbl;
> SELECT 5
> regression=# PREPARE prepstmt2(bigint) AS SELECT * FROM pcachetest
> WHERE q1 = $1;'
> PREPARE
> regression=# alter table pcachetest rename q1 to x;
> ALTER TABLE
> regression=# EXECUTE prepstmt2(123);
> 2023-08-29 17:23:59.148 CST [1382074] ERROR:  column "q1" does not
> exist at character 61
> 2023-08-29 17:23:59.148 CST [1382074] HINT:  Perhaps you meant to
> reference the column "pcachetest.q2".
> 2023-08-29 17:23:59.148 CST [1382074] STATEMENT:  EXECUTE prepstmt2(123);
> ERROR:  column "q1" does not exist
> HINT:  Perhaps you meant to reference the column "pcachetest.q2".

Thank you for the full set of commands. In that case the issue you're
describing is completely separate from this patch. The STATEMENT: part
of the log will always show the query that was received by the server.
This behaviour was already present even without my patch (I double
checked with PG15.3).



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Standardize spelling of "power of two"
Next
From: Alvaro Herrera
Date:
Subject: Re: tablecmds.c/MergeAttributes() cleanup