Re: [HACKERS] Cached plans and statement generalization
| От | Doug Doole |
|---|---|
| Тема | Re: [HACKERS] Cached plans and statement generalization |
| Дата | |
| Msg-id | CAP6UvaO9bS8+U-Upt-1Fkn7tgUyNW_BiCFbh9a4LgcHqh84kQw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] Cached plans and statement generalization (Andres Freund <andres@anarazel.de>) |
| Ответы |
Re: [HACKERS] Cached plans and statement generalization
Re: [HACKERS] Cached plans and statement generalization |
| Список | pgsql-hackers |
(FWIW, on this list we don't do top-quotes)
I know. Forgot and just did "reply all". My bad.
It's not always that simple, at least in postgres, unless you disregard
search_path. Consider e.g. cases like
CREATE SCHEMA a;
CREATE SCHEMA b;
CREATE TABLE a.foobar(somecol int);
SET search_patch = 'b,a';
SELECT * FROM foobar;
CREATE TABLE b.foobar(anothercol int);
SELECT * FROM foobar; -- may not be cached plan from before!
it sounds - my memory of DB2 is very faint, and I never used it much -
like similar issues could arise in DB2 too?
DB2 does handle this case. Unfortunately I don't know the details of how it worked though.
A naive option would be to invalidate anything that depends on table or view *.FOOBAR. You could probably make it a bit smarter by also requiring that schema A appear in the path.
- Doug
В списке pgsql-hackers по дате отправления: