Re: Support prepared statement invalidation when result types change

Поиск
Список
Период
Сортировка
От Jelte Fennema
Тема Re: Support prepared statement invalidation when result types change
Дата
Msg-id CAGECzQT0Hf6_6m_KhKDvmy2Kanxm543nhq80t_O+_C1e=0WwLg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Support prepared statement invalidation when result types change  (jian he <jian.universality@gmail.com>)
Ответы Re: Support prepared statement invalidation when result types change  (Jelte Fennema <me@jeltef.nl>)
Список 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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Standardize spelling of "power of two"
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: tablecmds.c/MergeAttributes() cleanup