Re: search_path for PL/pgSQL functions partially cached? - Mailing list pgsql-general

From David G. Johnston
Subject Re: search_path for PL/pgSQL functions partially cached?
Date
Msg-id CAKFQuwYrWzaJSg9YoV4zGsAbNsBCwG9JsupzwWXm1zRM9-5XaQ@mail.gmail.com
Whole thread Raw
In response to Re: search_path for PL/pgSQL functions partially cached?  (Jan Behrens <jbe-mlist@magnetkern.de>)
List pgsql-general
On Saturday, January 4, 2025, Jan Behrens <jbe-mlist@magnetkern.de> wrote:

Even if

DECLARE "variable" "tbl"."col"%TYPE;

follows *after* the schema is set to "myschema" in the example above, I
still get differing results, depending on how the search_path was set
when the function was first called.

I think this has to do with the fact that the overall structure and
probably types(?) are parsed first?

I concur that this dynamic doesn’t seem to be discussed.  Namely that in the presence of nested blocks the parse phase resolves placeholders for all declared variables without executing any expressions in the body of the function; therefore all types will be resolved seeing the same search_path, namely that of the calling session or established using SET.  Changing the search_path within an outer function body block will not affect declarations within an inner block. (I am not sure whether the for-loop cases are exceptional in this.)

David J.

pgsql-general by date:

Previous
From: Jan Behrens
Date:
Subject: Re: search_path for PL/pgSQL functions partially cached?
Next
From: "David G. Johnston"
Date:
Subject: Re: search_path for PL/pgSQL functions partially cached?