doc-gen: Migrate windows functions from code based documentation to attribute based

[comphead]

Is your feature request related to a problem or challenge?

It is needed to migrate whenever it is possible window UDF documentation from code based to attribute based.

Function list can be found in SessionStateDefaults::default_window_functions()

Example can be found https://github.com/apache/datafusion/pull/13646/files#diff-1528bf73810e3fb12fd1d4e76a8b46acb650549ef37d3c131464e087f97ca515L25

The translation can be done manually or in semi automatic way, uncommenting a function in PR #13669 locally. This will generate local text files with attribute text which can be copy pasted to structs. However its still needed to remove code based documentation manually, add imports, etc

Please refer to PR #13646 which completed the migration for aggregation functions

Describe the solution you'd like

No response

Describe alternatives you've considered

No response

Additional context

No response

[zjregee]

take

[zjregee]

Hi, @comphead, I'm confused on how to handle the following situation, can you give me some advice?

impl WindowUDFImpl for NthValue {
    fn documentation(&self) -> Option<&Documentation> {
        match self.kind {
            NthValueKind::First => Some(get_first_value_doc()),
            NthValueKind::Last => Some(get_last_value_doc()),
            NthValueKind::Nth => Some(get_nth_value_doc()),
        }
    }
}

Taking NthValue as an example, it implements different window functions through the enumeration value of its own type. How should I add user_doc for it? Do I need to modify user_doc itself to support this scenario?

[comphead]

Hi, @comphead, I'm confused on how to handle the following situation, can you give me some advice?

impl WindowUDFImpl for NthValue {
    fn documentation(&self) -> Option<&Documentation> {
        match self.kind {
            NthValueKind::First => Some(get_first_value_doc()),
            NthValueKind::Last => Some(get_last_value_doc()),
            NthValueKind::Nth => Some(get_nth_value_doc()),
        }
    }
}

Taking NthValue as an example, it implements different window functions through the enumeration value of its own type. How should I add user_doc for it? Do I need to modify user_doc itself to support this scenario?

For cases like that let's leave it as is.
I also faced the same scenario with invariants for aggregated functions, I dont think we can do much about it.

My understanding we can migrate 90%-ish of documentation to attributes still allowing for developers to implement API approach.

Perhaps in future we can expand user_doc and support enums but now it would be slightly prematurely