On Tue, Aug 14, 2018 at 04:23:33PM -0400, Robert Haas wrote: > 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.
What we are doing is more like C++ virtual functions, where the class calling it can replace function calls in subfunctions: https://www.geeksforgeeks.org/virtual-function-cpp/ > 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 I think we decide that search path alone for functions is insufficient because of data type matching, unless the schema is secure. > 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. So you are saying PG functions should lock down their search path at function definition time, and use that for all function invocations? -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +