Re: export FUNC_MAX_ARGS as a read-only GUC variable

Bruce Momjian wrote:
> Joe Conway wrote:
>>name       | block_size
>
> OK.  Should that be page_size?  Not sure but block size sounds more like
> a hardware setting.  I know we call it BLCKSZ in our code but page size
> seems more appropriate.  Not sure.

Seems like block_size is more appropriate to me. Any other opinions out
there? In bufpage.h I see this description of a page:

/*
  * A postgres disk page is an abstraction layered on top of a postgres
  * disk block (which is simply a unit of i/o, see block.h).

I guess the ral question is whether the uses for this information really
care about block size or page size -- i.e. if they weren't the same,
which would be the one you want to know?

>>name       | func_max_args
>>name       | index_max_keys
> Should that be max_func_args and max_index_args?  Seems more natural.
> Should we spell out function?  Probably.  We already have
> check_*function*_bodies.

Agreed. Now:
name       | max_function_args
name       | max_identifier_length
name       | max_index_keys

>>name       | integer_datetimes
>>short_desc | Datetimes are integer based
>
> This one has me confused.  "Datetimes are integer based" is a statement,
> as is the variable name.  Should it be "integer_datetime_storage" or
> something else?

Well the configure option is:
--enable-integer-datetimes
so "integer_datetimes" seemed natural to me.

The description is a statement because the option is boolean, i.e. the
statement "Datetimes are integer based" is either "true" or "false"
("on" or "off", etc). How stongly do you feel about it? I don't think
"integer_datetime_storage" is accurate in any case.

>>name       | name_data_len
> Is "name" a good description, or is "identifier" better, identifier_length?

Agreed -- see above.

Joe