Re: Cached plans and statement generalization

On 4/25/17, 6:34 PM, "pgsql-hackers-owner(at)postgresql(dot)org on behalf of Andres Freund" <pgsql-hackers-owner(at)postgresql(dot)org on behalf of andres(at)anarazel(dot)de> wrote:

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?

Greetings,

Andres Freund


--
Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

You may need to store the reloid of each relation in the cached query to ensure that the schema bindings are the same, and also invalidate dependent cache entries if a referenced relation is dropped.

Regards,

Jim Finnerty