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