On 04/26/2017 08:08 PM, Doug Doole wrote:
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.
This has been rumbling around in my head. I wonder if you could solve this
problem by registering dependencies on objects which don't yet exist. Consider:
CREATE TABLE C.T1(...);
CREATE TABLE C.T2(...);
SET search_path='A,B,C,D';
SELECT * FROM C.T1, T2;
For T1, you'd register a hard dependency on C.T1 and no virtual dependencies
since the table is explicitly qualified.
For T2, you'd register a hard dependency on C.T2 since that is the table that was selected for the query. You'd also register virtual dependencies on A.T2 and B.T2 since if either of those tables (or views) are created you need to recompile the
statement. (Note that no virtual dependency is created on D.T2() since that table would never be selected by the compiler.)
The catch is that virtual dependencies would have to be recorded and searched
as strings, not OIDs since the objects don't exist. Virtual dependencies only
have to be checked during CREATE processing though, so that might not be too
bad.
But this is getting off topic - I just wanted to capture the idea while it was
rumbling around.
I think that it will be enough to handle modification of search path and
invalidate prepared statements cache in this case.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
