Re: export FUNC_MAX_ARGS as a read-only GUC variable (was: [GENERAL] SELECT Question)

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