(Bug? or Intended?) Inconsistent search_path Behavior in Function Calls via Materialized View in PostgreSQL 17 - Mailing list pgsql-bugs
I just upgrade from postgres 14 to 17 and found Inconsistent search_path Behavior in Function Calls via Materialized View in PostgreSQL 17
Summary
According to image attached, when calling a function directly, it respects the configured
search_path (public). However, when the same function is invoked through a REFRESH MATERIALIZED VIEW, the search_path defaults to pg_catalog, pg_temp, causing relation lookup failures. (the postgres 14 is consistency while postgres 17 is not)Expected Behavior
- The function should inherit the
search_pathfrom its session (public). - The behavior of function execution should be consistent whether called directly or indirectly via a Materialized View.
Actual Behavior (postgres 17)
- Calling the function directly works fine (
search_path = public). - Calling the function through a Materialized View defaults
search_pathtopg_catalog, pg_temp, causing it to fail to find tables
Environment Details
Configuration: search_path = 'public' in pg 17 && search_path = '"$user," public' in pg14
Possible Causes / Thoughts
- The function execution context in a
REFRESH MATERIALIZED VIEWmay not inheritsearch_pathcorrectly. - PostgreSQL’s security model in newer versions (15+) might enforce a stricter
search_pathdefault (pg_catalog, pg_temp) inside Materialized View refresh execution ???? (which I have not found in web's document)
Regard.
pgsql-bugs by date: