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

Поиск
Список
Период
Сортировка
От dld
Тема Early binding of CURRENT_SCHEMA (Was: CREATE FUNCTION ... SEARCH {, DEFAULT | SYSTEM | SESSION })
Дата
Msg-id b1c19418-5022-8707-f8b7-b3f9a6a02b9f@casema.nl
обсуждение исходный текст
Ответы Re: Early binding of CURRENT_SCHEMA (Was: CREATE FUNCTION ... SEARCH {, DEFAULT | SYSTEM | SESSION })  (Erik Wienhold <ewie@ewie.name>)
Список 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

Вложения

В списке pgsql-general по дате отправления:

Предыдущее
От: Adrian Klaver
Дата:
Сообщение: Re: Postgres 11.5 not logging all sqls
Следующее
От: pgchem pgchem
Дата:
Сообщение: Is the logfile the only place to find the finish LSN?