Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs
Дата
Msg-id 20180221073550.GA1632@paquier.xyz
обсуждение исходный текст
Ответ на Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs  (Arthur Zakirov <a.zakirov@postgrespro.ru>)
Ответы Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs
Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs
Список pgsql-hackers
On Tue, Feb 20, 2018 at 06:46:57PM +0300, Arthur Zakirov wrote:
> Just 2 cents from me. It seems that there is a problem with extensions
> GUCs.
>
> [...]
>
> =# SELECT pg_get_functiondef('func_with_set_params'::regproc);
> ERROR:  unrecognized configuration parameter "plpgsql.extra_errors"

You have an excellent point here, and I did not consider it.
For pg_dump and pg_dumpall, something like what I described in
https://www.postgresql.org/message-id/20180112012440.GA2222@paquier.xyz
to extend pg_settings so as GUC types are visible via SQL could make
sense, now it is really a lot for just being able to quote parameters
correctly.  On top of that, what I suggested previously would not work
reliably except if we have pg_get_functiondef load the library
associated to a given parameter.  Even in this case there could
perfectly be a custom parameter from another plugin and not a parameter
associated to the function language itself.

It seems to me that this brings us back to a best-effort for the backend
and the frontend by maintaining a list of hardcoded parameter names,
which could be refined a maximum by considering lists for in-core
extensions and perhaps the most famous extensions around :(

Thoughts?
--
Michael

Вложения

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

Предыдущее
От: "Tsunakawa, Takayuki"
Дата:
Сообщение: RE: Speed up the removal of WAL files
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Speed up the removal of WAL files