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!"
>
>

Reply via email to