ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp> 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
