On Thu, Mar 10, 2016 at 11:48 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> Hmm. The meaning of funcs.inline depends on the search_path, not just >> during dump restoration but all the time. So anything uses it under a >> different search_path setting than the normal one will have this kind >> of problem; not just dump/restore. > > Yeah, I see no reason to claim that this is a dump/restore-specific > problem. > >> I don't have a very good idea what to do about that. > > The safe way to write SQL-language functions to be search-path-proof > is to schema-qualify the names in them, or to add a "SET search_path" > clause to the function definition. > > The problem with the latter approach is that it defeats inlining. > I thought for a minute that maybe we could teach the planner to do > inlining anyway by parsing the function body with the adjusted > search_path, but that doesn't really preserve the same semantics > (a SET would change the environment for called functions too).
Let's introduce a new variant of SET that only affects the lexical scope of the function to which it is attached, and then do what you said. That would be full of win, because actually I think in nearly every case that's the behavior people actually want. There's a reason why (for example) Perl started out with dynamic scoping (local) and then eventually introduced lexical scoping (my): it's because lexical scoping makes writing correct programs easier to a greater degree than dynamic scoping. That's basically the same problem we're hitting here - and not only here. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers