Postgres Pro
Downloads
Home   >   mailing lists

Thread: (Bug? or Intended?) Inconsistent search_path Behavior in Function Calls via Materialized View in PostgreSQL 17

(Bug? or Intended?) Inconsistent search_path Behavior in Function Calls via Materialized View in PostgreSQL 17

From
Kanitchet Vaiassava
Date:
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_path from 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_path to pg_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 VIEW may not inherit search_path correctly.
  • PostgreSQL’s security model in newer versions (15+) might enforce a stricter search_path default (pg_catalog, pg_temp) inside Materialized View refresh execution ???? (which I have not found in web's document)


image-mb1.png
image-mb2.png


Regard.

Re: (Bug? or Intended?) Inconsistent search_path Behavior in Function Calls via Materialized View in PostgreSQL 17

From
Tom Lane
Date:
Kanitchet Vaiassava <kanichet@hotmail.com> writes:
> Actual Behavior (postgres 17)
>   *   Calling the function directly works fine (search_path = public).
>   *   Calling the function through a Materialized View defaults search_path to pg_catalog, pg_temp, causing it to
failto find tables 

This is an intentional change in v17.

>   *   PostgreSQL’s security model in newer versions (15+) might enforce a stricter search_path default (pg_catalog,
pg_temp)inside Materialized View refresh execution ???? (which I have not found in web's document) 

It's the first compatibility issue listed in the v17 release notes:

https://www.postgresql.org/docs/17/release-17.html#RELEASE-17-MIGRATION

            regards, tom lane