Joe Conway <mail@joeconway.com> writes:
> First installment. The attached exports FUNC_MAX_ARGS as a read-only GUC
> variable -- func_max_args. Comments?
One could make a good case that INDEX_MAX_KEYS should be exported along
with FUNC_MAX_ARGS, rather than letting people write client code that
assumes they are the same.
I was intending to propose that we also export the following as
read-only variables:
* NAMEDATALEN
* BLCKSZ
* integer-vs-float datetime flag
(Not sure about suitable GUC names for these --- func_max_args isn't out
of line as a GUC name, but surely BLCKSZ is.) NAMEDATALEN is needed for
many of the same reasons as FUNC_MAX_ARGS. BLCKSZ is probably useful
for pg_autovacuum. The datetime representation flag will be important
when people start using binary data transmission seriously --- without
it you can't tell what you'll get for a timestamp value. Essentially,
these are things we currently tell people to use pg_controldata to find
out, but that's quite an inconvenient solution.
> While I was in guc.c, I also added short_desc to the definition of the
> pg_settings view. I wasn't sure if I ought to add the long_desc too, and
> if so, should it be it's own column in the view, or be concatenated with
> short_desc -- any thoughts on that?
If it's there it should be separate. I think also there was some
feeling it should be called "extra_desc" not "long_desc".
> + /* Can't be set in postgresql.conf */
> + {"func_max_args", PGC_INTERNAL, UNGROUPED,
> + gettext_noop("Shows the compiled-in maximum number of function "
> + "arguments."),
> + NULL
> + },
> + &func_max_args,
> + FUNC_MAX_ARGS, FUNC_MAX_ARGS, FUNC_MAX_ARGS, NULL, NULL
> + },
Please set the GUC_NOT_IN_SAMPLE and GUC_DISALLOW_IN_FILE flag bits on
each of these variables, too. I know we are not using these flags for
anything yet, but we should try to get them right...
regards, tom lane