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 :(
I afraid so there is not good solution. Is possible to store options in original form? When the function will be displayed, then the original value will be displayed. The current patch (with known extensions) can be used as bug fix and back patched. In new version we store original value with quotes.
