It seems that it matters *both* how the search_path was set during the *first* invocation of the function within a session *and* how it is set during the actual call of the function. So even if there are just two schemas involved, there are 4 possible outcomes for the "run" function's result ('2.4', '2', '5', and '5.4'). To me, this behavior seems to be somewhat dangerous. Maybe it is even considered a bug?
It is what it is - and if one is not careful one can end up writing hard-to-understand and possibly buggy code due to the various execution environments and caches involved.
I’ve never really understood why “%TYPE’ exists…
Or is it documented somewhere?
Can someone explain to me what's going on, and what is the best practice to deal with it? Is there a way to avoid fully qualifying every type and _expression_? Which parts do I have to qualify or is this something that could be fixed in a future version of PostgreSQL?
Add qualification or attach a “set search_path” clause to “create function”. Code stored in the server should not rely on the session search_path.
David J.
