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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kanitchet Vaiassava <kanichet(at)hotmail(dot)com>
Cc: "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: (Bug? or Intended?) Inconsistent search_path Behavior in Function Calls via Materialized View in PostgreSQL 17
Date: 2025-02-17 15:34:16
Message-ID: 823491.1739806456@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Kanitchet Vaiassava <kanichet(at)hotmail(dot)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 fail to 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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Andrew Dunstan 2025-02-17 15:44:17 Re: BUG #18816: pg16 requires perl 5.14+ but is not documented
Previous Message Tom Lane 2025-02-17 15:31:08 Re: issue with PSQL 17.1 on Suse 15 Linux SP6