|From:||Chapman Flack <chap(at)anastigmatix(dot)net>|
|Subject:||Re: Facility for detecting insecure object naming|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 08/16/18 21:31, Bruce Momjian wrote:
> I understand you don't like that a search_path changed by a function is
> passed down to functions it calls, but what would you like the system to
> use as a search path for called functions? The search path of the
This is beginning to sound like an exercise in /emulating/ lexical scoping
in a system that can run bits of code supplied in many different PLs, not
all of which can necessarily participate in "real" lexical scoping.
It could look like another flavor of setting a GUC. There's SET SESSION,
SET LOCAL, and maybe now SET LEXICAL. The key to the emulation is to
temporarily unstack the SET LEXICAL when the function it "lexically"
applies to makes calls to other functions. And restack it when those
other functions return.
Then there's room for bikeshedding on just where those unstacks/restacks
happen. I would think at clearly defined places in the core code, so as
to be independent of any PL. Any execution of command/query through SPI ?
Any function call through fmgr?
Emulating lexical scoping through dynamic means will have an overhead.
The usual use case would not involve a SET LEXICAL command issued on
its own, but such a command bound into a function declaration, as the
current SET commands can be. /Some/ PLs may be amenable to a static
analysis able to determine what objects are referred to in the code
and bind those ahead of time. Maybe, like the lanvalidator entry in
pg_language, there could be a lanprebind function, for those PLs
where that's tractable, and it would be called when the function is
created with any "lexically" bound variables. Record with each function
whether lanprebind returned success; if it did, skip the dynamic variable
futzing around calls to that function.
If the PL has no lanprebind function, or if it returned no-can-do for
a particular function and set of lexical settings, then the dynamic
emulation steps in.
Sounds a bit elaborate, but as it happens, there are further reasons
it could be good to have such "lexical" settings. There are some called
for in the SQL standard, for example. 
|Next Message||Yugo Nagata||2018-08-17 03:02:57||Re: has_table_privilege for a table in unprivileged schema causes an error|
|Previous Message||Michael Paquier||2018-08-17 02:47:19||Re: Fix help option of contrib/oid2name|