This is great Robert, I had started to make a list of things to cover (syntax, etc.) and you have all of the ones I thought of plus more. Thanks so much.

What is the NOLINT for on line 73?

The new fields are the obvious ones I found in the existing docs. Perhaps there are more and it should not be too difficult to add them.

NOLINT is just to suppress a linter warning about a missing explicit specifier. No bad things will happen if this specifier is not there.

Interestingly, FastTest still fails, I remember that it was green in my local environment. Let me check again.

I like idea of #36023 issue for arguments (or signature) of functions.

Ie it will look like:

SELECT name, is_aggregate, case_insensitive, origin, arguments, argument_types FROM system.functions WHERE name = 'uniq' OR name = 'has' OR name = 'concat';

I like idea of #36023 issue for arguments (or signature) of functions.

Ie it will look like:

SELECT name, is_aggregate, case_insensitive, origin, arguments, argument_types FROM system.functions WHERE name = 'uniq' OR name = 'has' OR name = 'concat';

Thanks @UnamedRus

Would arguments and syntax provide the functionality that you asked for @sarah-mdv

arguments

syntax

A few thoughts:

• While this PR adds new columns to system.functions, these are deliberately not publicly documented for now (here), because it is not 100% clear yet which fields make the most sense, how they are populated and formatted in the system table.
• I generally like the idea of FEATURE: Add function signatures to information returned when querying system.functions  #36023. Using reflection to populate system.functions has a certain charm. Unfortunately, functions currently neither communicate their arguments (mandatory or optional) nor the datatypes of the arguments to the function factory which would be the most natural place to collect such information. Instead, arguments/datatypes are "implicitly" encoded individually for each function, making it infeasible to extract the information automatically (at least for now).
• This doesn't mean that there can not or should not be a standardized way of instrumenting functions with signature "metadata" for use in reflection in future. Imho, this is orthogonal to this PR which focuses on generating web documentation from embedded documentation. E.g. we could have "duplicate" columns for different representations of the same information in system.functions - a human-readable column and a machine-readable column.
• About human-readable signature information (i.e. everything below official function docs): Documentation of the arguments and sometimes also of the return type need a description to be useful. So this information needs to be embedded in the source as well.

I have one more column to suggest, but I have to think about what it should be named. Let me start with the problem statement:

Our settings documentation has settings that should be set in /etc/clickhouse/server/config.d/filename.xml, some that should be in a specific section of ...users.d/filename.xml, some that should be set on a session basis, and some that should be set in a user's profile in Cloud. (are there more options? I don't think so). I think that we need a list of places/methods for configuring these settings.

Example, if you configure max_concurrent_connections_for_all_users in config.d, ClickHouse will not start.

Maybe the column is configuration?

@DanRoscigno Completely agree. Note that docs for settings docs follow a different "template" than function docs. E.g. only the former has "default value" and "possible values" fields. Also, settings docs are exposed in a different system table (this one). I think we should build (in a separate PR) a second C++ Documentation class specifically tailored to the needs of settings documentation.

@DanRoscigno Completely agree. Note that docs for settings docs follow a different "template" than function docs. E.g. only the former has "default value" and "possible values" fields. Also, settings docs are exposed in a different system table (this one). I think we should build (in a separate PR) a second C++ Documentation class specifically tailored to the needs of settings documentation.

Agreed, I will work on that this morning. Thanks again!