Re: let's make the list of reportable GUCs configurable (was Re: Add%r substitution for psql prompts to show recovery status)
От | Robert Haas |
---|---|
Тема | Re: let's make the list of reportable GUCs configurable (was Re: Add%r substitution for psql prompts to show recovery status) |
Дата | |
Msg-id | CA+TgmobY-OzPiM8kjWfL9j+VPrx-X_J8KNPMtoCALcfXVXBa5Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: let's make the list of reportable GUCs configurable (was Re: Add%r substitution for psql prompts to show recovery status) (Dave Cramer <pg@fastcrypt.com>) |
Список | pgsql-hackers |
On Thu, Jul 11, 2019 at 3:16 PM Dave Cramer <pg@fastcrypt.com> wrote: > On Thu, 11 Jul 2019 at 15:07, Robert Haas <robertmhaas@gmail.com> wrote: >> On Thu, Jul 11, 2019 at 2:29 PM Dave Cramer <pg@fastcrypt.com> wrote: >> > So if I understand this correctly if user bob has altered his search path and there is a security-definer function calledowned by him then >> > the search path will be changed for the duration of the function and reported for every iteration? The implicationsof this are "interesting" to say the least. >> >> I don't believe that it matters what search path has been set using >> ALTER USER bob. > > Why wouldn't it ??? Because the search_path used to execute a security definer function has nothing to do with the search_path that would be applied to a new session created by bob. Unless I am confused. But you can easily test this. Just make a security-definer function that prints its search_path and experiment. I think what's going to happen is that it'll inherit the search_path from the surrounding session unless you use ALTER FUNCTION .. SET, and that ALTER USER will make no difference. Sometimes I'm wrong, though. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: