| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | "Imseih (AWS), Sami" <simseih(at)amazon(dot)com> |
| Cc: | Andrei Lepikhov <lepihov(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, kaido vaikla <kaido(dot)vaikla(at)gmail(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: query_id, pg_stat_activity, extended query protocol |
| Date: | 2024-04-27 14:18:57 |
| Message-ID: | CAKFQuwYyMAg9O4zG-JEf17aJhV2y5wQ=-kDv3xMmzenptPqVTA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Apr 27, 2024 at 6:55 AM Imseih (AWS), Sami <simseih(at)amazon(dot)com>
wrote:
>
> Hmm, you raise a good point. Isn't this a fundamental problem
> with prepared statements? If there is DDL on the
> relations of the prepared statement query, shouldn't the prepared
> statement be considered invalid at that point and raise an error
> to the user?
>
>
We choose a arguably more user-friendly option:
https://www.postgresql.org/docs/current/sql-prepare.html
"""
Although the main point of a prepared statement is to avoid repeated parse
analysis and planning of the statement, PostgreSQL will force re-analysis
and re-planning of the statement before using it whenever database objects
used in the statement have undergone definitional (DDL) changes or their
planner statistics have been updated since the previous use of the prepared
statement.
"""
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Imseih (AWS), Sami | 2024-04-27 14:57:44 | Re: query_id, pg_stat_activity, extended query protocol |
| Previous Message | Imseih (AWS), Sami | 2024-04-27 13:54:57 | Re: query_id, pg_stat_activity, extended query protocol |