Re: query_id, pg_stat_activity, extended query protocol

Поиск
Список
Период
Сортировка
От Andrei Lepikhov
Тема Re: query_id, pg_stat_activity, extended query protocol
Дата
Msg-id b7470e80-7f95-4cdb-a711-3938df54a662@gmail.com
обсуждение исходный текст
Ответ на Re: query_id, pg_stat_activity, extended query protocol  ("Imseih (AWS), Sami" <simseih@amazon.com>)
Ответы Re: query_id, pg_stat_activity, extended query protocol  ("Imseih (AWS), Sami" <simseih@amazon.com>)
Список pgsql-hackers
On 27/4/2024 20:54, Imseih (AWS), Sami wrote:
>> But simplistic case with a prepared statement shows how the value of
>> queryId can be changed if you don't acquire all the objects needed for
>> the execution:
> 
> 
>> CREATE TABLE test();
>> PREPARE name AS SELECT * FROM test;
>> EXPLAIN (ANALYSE, VERBOSE, COSTS OFF) EXECUTE name;
>> DROP TABLE test;
>> CREATE TABLE test();
>> EXPLAIN (ANALYSE, VERBOSE, COSTS OFF) EXECUTE name;
> 
> 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?
I don't think so. It may be any object, even stored procedure, that can 
be changed. IMO, the right option here is to report zero (like the 
undefined value of queryId) until the end of the parsing stage.

-- 
regards, Andrei Lepikhov




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alexander Korotkov
Дата:
Сообщение: Re: Add SPLIT PARTITION/MERGE PARTITIONS commands
Следующее
От: Andy Fan
Дата:
Сообщение: Re: using extended statistics to improve join estimates