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 |
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 |