Re: [17] Special search_path names "!pg_temp" and "!pg_catalog"

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [17] Special search_path names "!pg_temp" and "!pg_catalog"
Date: 2023-08-21 16:08:43
Message-ID: aaaeed9d3c93868cf55c0e6279f6a48189b12988.camel@j-davis.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, 2023-08-19 at 07:18 +0200, Pavel Stehule wrote:
> cannot be better special syntax
>
> CREATE OR REPLACE FUNCTION xxx()
> RETURNS yyy AS $$ ... $$$
> SET SEARCH_PATH DISABLE
>
> with possible next modification
>
> SET SEARCH_PATH CATALOG .. only for pg_catalog
> SET SEARCH_PATH MINIMAL .. pg_catalog, pg_temp

I agree that we should consider new syntax, and there's a related
discussion here:

https://www.postgresql.org/message-id/flat/2710f56add351a1ed553efb677408e51b060e67c(dot)camel(at)j-davis(dot)com

Regardless, even with syntax changes, we need something to print when
someone does a "SHOW search_path", i.e. some representation that
indicates pg_temp is excluded. That way it can also be saved and
restored.

> I question if we should block search path settings when this setting
> is used. Although I set search_path, the search_path can be
> overwritten in function of inside some nesting calls

If so, that should be a separate feature. For the purposes of this
thread, we just need a way to represent a search path that excludes
pg_temp and/or pg_catalog.

Regards,
Jeff Davis

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jacob Champion 2023-08-21 17:49:16 Re: Logging of matching pg_hba.conf entry during auth skips trust auth, potential security issue
Previous Message Andrew Dunstan 2023-08-21 15:51:24 Re: Make all Perl warnings fatal