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

Tom Lane wrote:
> I was thinking of proposing that we provide something just about like
> that as a standard function (written in C, not in plpgsql, so that it
> would be available whether or not you'd installed plpgsql). There are
> some places in the information_schema that desperately need it ---
> right now, the value of FUNC_MAX_ARGS is effectively hard-wired into
> some of the information_schema views, which means they are broken if
> one changes that #define. We could fix this if we had a function like
> the above and exported FUNC_MAX_ARGS as a read-only GUC variable.
>

First installment. The attached exports FUNC_MAX_ARGS as a read-only GUC
variable -- func_max_args. Comments?

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?

Current output looks like this:

regression=# \x
Expanded display is on.
regression=# select * from pg_settings where name = 'func_max_args';
-[ RECORD 1 ]-----------------------------------------------------------
name | func_max_args
setting | 32
short_desc | Shows the compiled-in maximum number of function arguments.
context | internal
vartype | integer
source | default
min_val | 32
max_val | 32

This will require a catalog version bump when I apply it (not done in
the attached patch).

Joe