| From: | Isaac Morland <isaac(dot)morland(at)gmail(dot)com> |
|---|---|
| To: | Jan Behrens <jbe-mlist(at)magnetkern(dot)de> |
| Cc: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, "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-03 23:36:13 |
| Message-ID: | CAMsGm5fVJzOZ6kNDwkiRuFZFW=cY=FZixaSOd=WRdP0QLdoqew@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Fri, 3 Jan 2025 at 18:22, Jan Behrens <jbe-mlist(at)magnetkern(dot)de> wrote:
> Instead, I plan to expect the function to receive a query string that
> will get the data that is being processed by the function.
>
> That query string should be allowed to refer to tables in the
> search_path at the caller's side.
>
> Therefore, I cannot use the "SET search_path FROM CURRENT" in my
> "CREATE FUNCTION" statement, because it would overwrite the current
> search_path on each call of the function.
>
I wonder if it would help if EXECUTE took an optional search_path to use
while executing the query.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Arbol One | 2025-01-04 11:08:58 | To uninstall or not to uninstall that is... |
| Previous Message | Jan Behrens | 2025-01-03 23:23:08 | Re: search_path for PL/pgSQL functions partially cached? |