Early binding of CURRENT_SCHEMA (Was: CREATE FUNCTION ... SEARCH {, DEFAULT | SYSTEM | SESSION }) - Mailing list pgsql-general

From dld
Subject Early binding of CURRENT_SCHEMA (Was: CREATE FUNCTION ... SEARCH {, DEFAULT | SYSTEM | SESSION })
Date
Msg-id b1c19418-5022-8707-f8b7-b3f9a6a02b9f@casema.nl
Whole thread Raw
Responses Re: Early binding of CURRENT_SCHEMA (Was: CREATE FUNCTION ... SEARCH {, DEFAULT | SYSTEM | SESSION })
List 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

pgsql-general by date:

Previous
From: Adrian Klaver
Date:
Subject: Re: Postgres 11.5 not logging all sqls
Next
From: pgchem pgchem
Date:
Subject: Is the logfile the only place to find the finish LSN?