I don't see why it shouldn't support other data types, but like Charles said, it should ideally be use case driven, since adding new data types bumps up the complexity level of the core code permanently. I don't see a reason to add every single SQL data type just because it exists, but it does make sense to me to add data types that add meaningful new capabilities or allow meaningful new optimizations. One would be "DECIMAL", would definitely be useful to have that one.
There is also the possibility of adding types that only exist in the SQL layer, for example adding "TIMESTAMP" or "DATE" types that under the hood are really just long (int64) columns. We do that right now for the __time column but that is a special-case, so you cannot currently add secondary TIMESTAMP columns. But it might be cool to allow it. On Fri, Mar 29, 2019 at 8:21 AM Charles Allen <charles.al...@snap.com.invalid> wrote: > For my team we start from the other direction. What are people DOING with > the data. For example, if they are doing counts and sums with basic > predicates, then in what ways does the existing feature set not meet those > needs? > > If they are doing other things, what is the end result they are trying to > achieve? > > Can you provide more context on the end use cases? > > On Fri, Mar 29, 2019, 12:24 AM zeng jienan <zeng4...@hotmail.com> wrote: > > > Hi, > > > > Will druid support other data types in the future? Such as boolean, byte, > > short, int. > > >
