Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

2018-02-21 8:35 GMT+01:00 Michael Paquier <michael@paquier.xyz>:

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.

Regards

Pavel

 

Thoughts?
--
Michael