From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: CREATE FUNCTION ... SEARCH { DEFAULT | SYSTEM | SESSION } |
Date: | 2023-09-25 16:00:39 |
Message-ID: | 9f128dd2-c1b4-be7d-1655-400d7485f64a@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 9/25/23 11:30, Robert Haas wrote:
> I don't believe that people want to run their functions under a
> sanitized search_path that only includes system schemas. That might
> work for some people, but I think most people will define functions
> that call other functions that they themselves defined, or access
> tables that they themselves created. They will therefore need the
> search_path to include the schemas in which they created those
> objects.
Without diving into all the detailed nuances of this discussion, this
particular paragraph made me wonder if at least part of the problem here
is that the same search_path is used to find "things that I want to
execute" (functions and operators) and "things I want to access"
(tables, etc).
I think many folks would be well served by only having system schemas in
the search_path for the former (augmented by explicit schema qualifying
of one's own functions), but agree that almost no one wants that for the
latter (needing to schema qualify every table reference).
Should there be a way to have a separate "execution" search_path?
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
From | Date | Subject | |
---|---|---|---|
Next Message | Matthias van de Meent | 2023-09-25 16:13:19 | Re: Improving btree performance through specializing by key shape, take 2 |
Previous Message | Tom Lane | 2023-09-25 15:33:43 | Re: Why need a lock? |