ITAGAKI Takahiro <[EMAIL PROTECTED]> writes: > Postgres supports to add custom GUC variables on runtime, but we > cannot use GUC flags in them. This patch adds the flags argument > to DefineCusomXxx() functions. The flags were always 0 until now.
Of course the problem with this is that it breaks every external module that is using the DefineCustom*Variable functions. I grant that we often change backend APIs in ways that break external modules, but it's a bit annoying to change an API that has no other purpose than to be called by external modules. Is the functionality to be gained worth that? Alternatively, should we uglify the patch by providing some form of backwards compatibility --- ie, invent new names for the new forms of the functions, and keep the old ones as-is? (I'm not really for that, but the question needs to be asked.) If we are going to change the API, I think we should take the opportunity to clean up another problem, which is the nonintuitive approach to establishing the new variable's boot_val default. ISTM that should be specified explicitly as an additional argument to DefineCustom*Variable. The current approach is that whatever is physically in the variable at the time of the call determines the default; this has confused people in the past http://archives.postgresql.org/pgsql-hackers/2006-11/msg00925.php and it's totally unlike the way things work for built-in GUC variables. Another API question: should we allow the new variable's group to be set to something other than CUSTOM_OPTIONS? I'm not sure that that's a good idea, since the config_group values are ad-hoc and subject to change. But again, now's the time to consider it. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers