On 4/25/17, 6:34 PM, "pgsql-hackers-ow...@postgresql.org on behalf of Andres
Freund" <pgsql-hackers-ow...@postgresql.org on behalf of and...@anarazel.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@postgresql.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
