Re: Per-function search_path => per-function GUC settings

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Per-function search_path => per-function GUC settings
Date: 2007-09-01 18:05:50
Message-ID: 22752.1188669950@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Gregory Stark <stark(at)enterprisedb(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2007-09-01 18:12:30 Re: [PATCH] Lazy xid assingment V2
Previous Message Tom Lane 2007-09-01 17:55:06 Re: Per-function search_path => per-function GUC settings