Re: Per-function search_path => per-function GUC settings - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Per-function search_path => per-function GUC settings
Date
Msg-id 22752.1188669950@sss.pgh.pa.us
Whole thread Raw
In response to Re: Per-function search_path => per-function GUC settings  (Gregory Stark <stark@enterprisedb.com>)
Responses Re: Per-function search_path => per-function GUC settings
List pgsql-hackers
Gregory Stark <stark@enterprisedb.com> writes:
> I think security definer functions should automatically inherit their
> search_path. The whole "secure by default" thing.

This assumes that the search path at creation time has something to do
with the path you'd like to use at execution, which is unlikely to be
the case in existing pg_dump output, to name one example.  I don't
really want to get into doing the above.

> It might be best to have a guc variable which controls the variables which are
> automatically saved. regexp_flavour and maybe a handful of others could be in
> it by default. But that might depend on how expensive it is at run-time. I
> wouldn't want trivial SQL functions to no longer be inline-able because one
> might one day use a regexp for example.

Well, security definer functions can't be inlined anyway, so as long as
you only try to do this for sec-def functions it wouldn't be an issue.
I just think it's too big a departure from existing behavior, and will
probably break more things than it fixes.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Per-function search_path => per-function GUC settings
Next
From: "Heikki Linnakangas"
Date:
Subject: Re: [PATCH] Lazy xid assingment V2