Re: [17] Special search_path names "!pg_temp" and "!pg_catalog" - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: [17] Special search_path names "!pg_temp" and "!pg_catalog"
Date
Msg-id 4c02c6651dbb7703ac188c9fae309414fe76aa82.camel@j-davis.com
Whole thread Raw
In response to Re: [17] Special search_path names "!pg_temp" and "!pg_catalog"  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: [17] Special search_path names "!pg_temp" and "!pg_catalog"
List pgsql-hackers
On Thu, 2023-10-26 at 16:28 -0500, Nathan Bossart wrote:
> On Fri, Aug 18, 2023 at 02:44:31PM -0700, Jeff Davis wrote:
> > +    SET search_path = admin, "!pg_temp";
>
> I think it's unfortunate that these new identifiers must be quoted. 
> I
> wonder if we could call these something like "no_pg_temp".  *shrug*

Do you, overall, find this feature useful?

Most functions don't need pg_temp, so it feels cleaner to exclude it.
But pg_temp is ignored for function/op lookup anyway, so functions
won't be exposed to search_path risks related to pg_temp unless they
are accessing tables.

If my proposal for the SEARCH clause got more support, I'd be more
excited about this feature because it could be set implicitly as part
of a safe search_path. Without the SEARCH clause, the only way to set
"!pg_temp" is by typing it out, and I'm not sure a lot of people will
actually do that.

Regards,
    Jeff Davis




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: race condition in pg_class
Next
From: Jeff Davis
Date:
Subject: Re: Improve WALRead() to suck data directly from WAL buffers when possible