drill-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Omernik <j...@omernik.com>
Subject Re: Dealing with bad data when trying to do date computations
Date Tue, 28 Feb 2017 18:20:27 GMT
You could also generate documentation updates via query at each release.
This would be a great feature, move the information close to the analysts
hands, I love how that would work.  (I think I remember some talk about
extending sys.options to be self documenting as well.... )



On Tue, Feb 28, 2017 at 12:11 PM, Jinfeng Ni <jni@apache.org> wrote:

> Regarding the list of functions (build-in or UDF), someone once
> suggested that we make the functions self-documented by adding a
> sys.functions table.
>
> select * from sys.functions where name like '%SPLIT%';
>
> return function_name, parameter_list, description etc.
>
> This way, use could simply query sys.functions using Drill.
>
>
>
>
>
>
>
> On Tue, Feb 28, 2017 at 9:02 AM, Jinfeng Ni <jni@apache.org> wrote:
> >> 4.  I think as part of developer review and pull requests that add
> >> functions/functionality should require a pull request to also provide a
> >> documentation update. This helps to ensure that the docs keep up to
> date,
> >> as well as keeping users appraised of what is happening... i.e. it's a
> good
> >> "feeling" to see a great tool like Drill "improving" with new
> >> functionality.
> >>
> >> Please, folks, we need to do some one time clean up (go back through
> pull
> >> requests to ensure all functions are documented up to now) and then then
> >> get processes in place to ensure ongoing updates.
> >>
> >
> > That's a good suggestion. We should try our best to keep the code and
> > doc in sync.
> >
> > +1
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message