Re: [HACKERS] Cached plans and statement generalization

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

It's not always that simple, at least in postgres, unless you disregard   search_path.  Consider e.g. cases like
CREATESCHEMA 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@postgresql.org)   To make
changesto 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,
andalso invalidate dependent cache entries if a referenced relation is dropped. 
 

Regards,
   Jim Finnerty