From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Jan Behrens <jbe-mlist(at)magnetkern(dot)de> |
Cc: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: search_path for PL/pgSQL functions partially cached? |
Date: | 2025-01-05 00:04:49 |
Message-ID: | CAKFQuwYrWzaJSg9YoV4zGsAbNsBCwG9JsupzwWXm1zRM9-5XaQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Saturday, January 4, 2025, Jan Behrens <jbe-mlist(at)magnetkern(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2025-01-05 01:19:22 | Re: search_path for PL/pgSQL functions partially cached? |
Previous Message | Jan Behrens | 2025-01-04 23:12:49 | Re: search_path for PL/pgSQL functions partially cached? |