comphead commented on issue #13670:
URL: https://github.com/apache/datafusion/issues/13670#issuecomment-2536507747
> Hi, @comphead, I'm confused on how to handle the following situation, can
you give me some advice?
>
> ```rust
> 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
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscr...@datafusion.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscr...@datafusion.apache.org
For additional commands, e-mail: github-h...@datafusion.apache.org
