Early binding of CURRENT_SCHEMA (Was: CREATE FUNCTION ... SEARCH {, DEFAULT | SYSTEM | SESSION })

From: dld <dld(at)casema(dot)nl>
To: pgsql-general(at)postgresql(dot)org
Subject: Early binding of CURRENT_SCHEMA (Was: CREATE FUNCTION ... SEARCH {, DEFAULT | SYSTEM | SESSION })
Date: 2023-09-26 12:44:44
Message-ID: b1c19418-5022-8707-f8b7-b3f9a6a02b9f@casema.nl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi there!

I followed the discussion about the schema resolution, and I really
think there is need for an early bound (at function definition time)
version of CURRENT_SCHEMA (the first member of search_path)

Avoiding hard-coding of schema names, (and avoiding polluting the actual
users schema) is hard.

My current code generates some plpgsql functions, which need some helper
functions to construct fcolumn lists, query fragments, etc.

These helpers should live in the same schema, IMHO

It is not impossible: I ended up with the following kludge to refer to
functions in the same schema as the calling function.

It involves an extra layer of dynamic SQL, which self-destructs after
use. It is not pretty, but it works.

Example of such a nested dynamic function is attached. (the helper
functions are not included, but they live in the same "compilation unit")

Cheers,

Adriaan van Kessel

Attachment Content-Type Size
snippet text/plain 2.8 KB

Responses

Browse pgsql-general by date

  From Date Subject
Next Message pgchem pgchem 2023-09-26 13:00:47 Is the logfile the only place to find the finish LSN?
Previous Message Adrian Klaver 2023-09-26 04:15:44 Re: Postgres 11.5 not logging all sqls