Re: search_path for PL/pgSQL functions partially cached?

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.

In response to

Browse pgsql-general by date

  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?