On Tue, Aug 14, 2018 at 3:31 PM, Bruce Momjian <bruce@momjian.us> wrote:
> Well, in C, if the calling function is not in the current C file, you
> really don't know what function you are linking to --- it depends on
> what other object files are linked into the executable.
True.
> I am unclear how lexical scoping helps with this, or with Postgres.
Well, if you say sqrt(x) in C, and you don't have sqrt or x defined in
the current function, you know that you're going to call a global
function called sqrt and pass to it a global variable called x.
You're not going to latch onto a local variable called x in the
function that called your function, and if the calling function has a
local variable called sqrt, that doesn't matter either. The linker
can point every called to sqrt() in the program at a different place
than expected, but you can't monkey with the behavior of an individual
call by having the calling function declare identifiers that mask the
ones the function intended to reference.
On the other hand, when you call an SQL-language function, or even to
some extent a plpgsql-language function, from PostgreSQL, you can in
fact change the meanings of every identifier that appears in that
function body unless those references are all schema-qualified or the
function sets the search path. If an SQL-language function calls
sqrt(x), you can set the search_path to some schema you've created
where there is a completely different sqrt() function than that
function intended to call. That is a very good way to make stuff (a)
break or (b) be insecure.
The point of having a lexically-scoped search path is that it is
generally the case that when you write SQL code, you know the search
path under which you want it to execute. You can get that behavior
today by attaching a SET clause to the function, but that defeats
inlining, is slower, and the search path you configure applies not
only to the code to which is attached but to any code which it in turn
calls. In other words, the search path setting which you configure
has dynamic scope. I submit that's bad. Functions can reasonably be
expected to know the search path that should be used to run the code
they actually contain, but they cannot and should not need to know the
search path that should be used to run code in other functions which
they happen to call.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company