On Tue, Aug 14, 2018 at 3:31 PM, Bruce Momjian <br...@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