I would also avoid `UNKNOWN` because of the mentioned reasons.
I'm fine with `RAW`. I will wait another day or two until I conclude the
discussion.
Thanks,
Timo
On 21.10.19 12:23, Jark Wu wrote:
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!"
