Re: CREATE FUNCTION ... SEARCH { DEFAULT | SYSTEM | SESSION }

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

In response to

Responses

Browse pgsql-hackers by date

  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?