On Wed, 2024-02-28 at 09:29 -0800, Jeff Davis wrote: > On Wed, 2024-02-28 at 10:55 -0600, Nathan Bossart wrote: > > I'm afraid I don't have a better idea than adding a short note in > > each > > affected commands's page. > > OK, that works for now.
Committed. The only changes are documentation and test updates. This is a behavior change, so it still carries some risk, though we've had a lot of discussion and generally it seems to be worth it. If it turns out worse than expected during beta, of course we can re-revert it. I will restate the risks here, which come basically from two places: (1) Functions called from index expressions which rely on search_path (and don't have a SET clause). Such a function would have already been fairly broken before my commit, because anyone accessing the table without the right search_path would have seen an error or wrong results. And there is no means to set the "right" search_path for autoanalyze or logical replication, so those would not have worked with such a broken function before my commit, no matter what. That being said, surely some users did have such broken functions, and with this commit, they will have to remedy them with a SET clause. Fortunately, the performance impact of doing so has been greatly reduced. (2) Matierialized views which call functions that rely on search_path (and don't have a SET clause). This is arguably a worse kind of breakage because materialized views are often refreshed only by the table owner, and it's easier to control search_path when running REFRESH. Additionally, functions called from materialized views are more likely to be "interesting" than functions called from an index expression. However, the remedy is straightforward: use a SET clause. Regards, Jeff Davis