On Friday, December 27, 2024, Jan Behrens <jbe-ml...@magnetkern.de> wrote:
>
>
> 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? https://www.postgresql.org/docs/current/plpgsql-implementation.html#PLPGSQL-PLAN-CACHING 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.
