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

[Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>]

Joe Conway <mail(at)joeconway(dot)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