Re: [HACKERS][BUG] Cache invalidation for queries that contains constof temporary composite type
От | Maksim Milyutin |
---|---|
Тема | Re: [HACKERS][BUG] Cache invalidation for queries that contains constof temporary composite type |
Дата | |
Msg-id | 2f82d35e-66c2-fa94-160e-59054a75c3c1@gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS][BUG] Cache invalidation for queries that contains constof temporary composite type (Alexander Korotkov <a.korotkov@postgrespro.ru>) |
Ответы |
Re: [HACKERS][BUG] Cache invalidation for queries that contains constof temporary composite type
|
Список | pgsql-hackers |
Hi, Alexander!
Thanks for the comments.
02.10.17 20:02, Alexander Korotkov wrote:
Please, register this patch at upcoming commitfest to ensure it wouldn't be forgotten.Regression test changes (both .sql and .out) are essential parts of the patch. I see no point in posting them separately. Please, incorporate them into your patch.
OK, I'll take your advice.
I have tested the following case:Did you check this patch with manually created composite type (made by CREATE TYPE typname AS ...)?
create type pair as (x int, y int);
prepare test as select json_populate_record(null::pair, '{"x": 1, "y": 2}'::json);
drop type pair cascade;
execute test;
-- The following output is obtained before patch
ERROR: cache lookup failed for type 16419
-- After applying patch
ERROR: type "pair" does not exist
But after recreating 'pair' type I'll get the following message:
ERROR: cached plan must not change result type
I don't know whether it's right behavior. Anyhow your point is a good motivation to experiment and investigate different scenarios of work with cached plan that depends on non-stable type. Thanks for that.
-- Regards, Maksim Milyutin
В списке pgsql-hackers по дате отправления: