Re: search_path and SET ROLE

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ron Johnson <ronljohnsonjr(at)gmail(dot)com>
Cc: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: search_path and SET ROLE
Date: 2024-05-22 17:10:19
Message-ID: 4165841.1716397819@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Ron Johnson <ronljohnsonjr(at)gmail(dot)com> writes:
> It seems that the search_path of the role that you SET ROLE to does not
> become the new search_path.

It does for me:

regression=# create role r1;
CREATE ROLE
regression=# create schema r1 authorization r1;
CREATE SCHEMA
regression=# select current_schemas(true), current_user;
current_schemas | current_user
---------------------+--------------
{pg_catalog,public} | postgres
(1 row)

regression=# set role r1;
SET
regression=> select current_schemas(true), current_user;
current_schemas | current_user
------------------------+--------------
{pg_catalog,r1,public} | r1
(1 row)

regression=> show search_path ;
search_path
-----------------
"$user", public
(1 row)

The fine manual says that $user tracks the result of
CURRENT_USER, and at least in this example it's doing that.
(I hasten to add that I would not swear there are no
bugs in this area.)

> Am I missing something, or is that PG's behavior?

I bet what you missed is granting (at least) USAGE on the
schema to that role. PG will silently ignore unreadable
schemas when computing the effective search path.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Ron Johnson 2024-05-22 17:47:59 Re: search_path and SET ROLE
Previous Message Tom Lane 2024-05-22 16:53:33 Re: Missed compiler optimization issue in function select_rtable_names_for_explain