I also think `UNKNOWN` is not suitable here. Because we already have `UNKNOWN` value in SQL, i.e. the three-valued logic (TRUE, FALSE, UNKNOWN) of BOOLEAN type. It will confuse users here, what's the relationship between them.
Best, Jark On Mon, 21 Oct 2019 at 17:53, Paul Lam <paullin3...@gmail.com> wrote: > Hi, > > IMHO, `UNKNOWN` does not fully reflects the situation here, because the > types are > actually “known” to users, and users just want to leave them out of Flink > type system. > > +1 for `RAW`, for it's more intuitive than `OPAQUE`. > > Best, > Paul Lam > > > 在 2019年10月21日，16:43，Kurt Young <ykt...@gmail.com> 写道： > > > > OPAQUE seems to be a little bit advanced to a lot non-english > > speakers (including me). I think Xuefu raised a good alternative: > > UNKNOWN. What do you think about it? > > > > Best, > > Kurt > > > > > > On Mon, Oct 21, 2019 at 3:49 PM Aljoscha Krettek <aljos...@apache.org> > > wrote: > > > >> I prefer OPAQUE compared to ANY because any is often the root object in > an > >> object hierarchy and would indicate to users the wrong thing. > >> > >> Aljoscha > >> > >>> On 18. Oct 2019, at 18:41, Xuefu Z <usxu...@gmail.com> wrote: > >>> > >>> Thanks to Timo for bringing up an interesting topic. > >>> > >>> Personally, "OPAQUE" doesn't seem very intuitive with respect to types. > >> (It > >>> suits pretty well to glasses, thought. :)) Anyway, could we just use > >>> "UNKNOWN", which is more explicit and true reflects its nature? > >>> > >>> Thanks, > >>> Xuefu > >>> > >>> > >>> On Fri, Oct 18, 2019 at 7:51 AM Timo Walther <twal...@apache.org> > wrote: > >>> > >>>> Hi everyone, > >>>> > >>>> Stephan pointed out that our naming of a generic/blackbox/opaque type > in > >>>> SQL might be not intuitive for users. As the term ANY rather > describes a > >>>> "super-class of all types" which is not the case in our type system. > Our > >>>> current ANY type stands for a type that is just a blackbox within SQL, > >>>> serialized by some custom serializer, that can only be modified within > >>>> UDFs. > >>>> > >>>> I also gathered feedback from a training instructor and native English > >>>> speaker (David in CC) where I received the following: > >>>> > >>>> "The way I’m thinking about this is this: there’s a concept here that > >>>> people have to become aware of, which is that Flink SQL is able to > >>>> operate generically on opaquely typed things — and folks need to be > able > >>>> to connect what they see in code examples, etc. with this concept > (which > >>>> they may be unaware of initially). > >>>> I feel like ANY misses the mark a little bit, but isn’t particularly > >>>> bad. I do worry that it may cause some confusion about its purpose and > >>>> power. I think OPAQUE would more clearly express what’s going on." > >>>> > >>>> Also resources like Wikipedia [1] show that this terminology is > common: > >>>> > >>>> "a data type whose concrete data structure is not defined [...] its > >>>> values can only be manipulated by calling subroutines that have access > >>>> to the missing information" > >>>> > >>>> I would therefore vote for refactoring the type name because it is not > >>>> used much yet. > >>>> > >>>> Implications are: > >>>> > >>>> - a new parser keyword "OPAQUE" and changed SQL parser > >>>> > >>>> - changes for logical type root, logical type visitors, and their > usages > >>>> > >>>> What do you think? > >>>> > >>>> Thanks, > >>>> > >>>> Timo > >>>> > >>>> [1] https://en.wikipedia.org/wiki/Opaque_data_type > >>>> > >>>> > >>>> > >>> > >>> -- > >>> Xuefu Zhang > >>> > >>> "In Honey We Trust!" > >> > >> > >
