Re: [HACKERS][BUG] Cache invalidation for queries that contains constof temporary composite type
От | Alexander Korotkov |
---|---|
Тема | Re: [HACKERS][BUG] Cache invalidation for queries that contains constof temporary composite type |
Дата | |
Msg-id | CAPpHfdtCuh5UVezbjA2W+a-tPqXQ6xjAjeH6yyZ1DzxHOSwfsQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS][BUG] Cache invalidation for queries that contains constof temporary composite type (Maksim Milyutin <milyutinma@gmail.com>) |
Ответы |
Re: [HACKERS][BUG] Cache invalidation for queries that containsconst of temporary composite type
|
Список | pgsql-hackers |
On Tue, Oct 3, 2017 at 12:20 AM, Maksim Milyutin <milyutinma@gmail.com> wrote:
I have tested the following case:
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.
I think ideally, cached plan should be automatically invalidated and stored procedure should work without error.
Not really sure if it's feasible...
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
В списке pgsql-hackers по дате отправления: