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 по дате отправления: