I don't think it would. We want to still do validation and we won't be returning a struct, we'll be returning one or the other. Think of this as a narrowing of the ANY type to a subset of known possibilities. Something that fits a particular possibility should be allowed but for example, in the (varbinary, varbinary[]) case, you should be able to use functions that only support varbinary or varbinary[] but not functions that expect int or varchar.
Without specifically stating c.i or c.ai, you wouldn't get any validation. Additionally, I'd expect the validator to reject valid expressions such as c + 4 (where c is the union field). On Wed, Dec 16, 2015 at 4:23 PM, andrew <[email protected]> wrote: > That sounds like it might fit the bill. Thanks Julien. > > > > On Dec 16, 2015, at 1:30 PM, Julian Hyde <[email protected]> wrote: > > > > You could declare a STRUCT(i INT, ai ARRAY(INT)) and make sure exactly > one of i and ai is set. > > > >> On Dec 16, 2015, at 10:51 AM, andrew <[email protected]> wrote: > >> > >> I’m wondering if it would be possible to add a UNION type in Calcite. > >> > >> My use case is that I am developing a backend storage engine using > Calcite that only partially declares its schema. Specifically, the engine > declares columns such as ‘int’ when it actually means the column can > contain ‘int’ or ‘array of int’. There is no way to tell without actually > reading the table if the data is scalar or array. Indeed it can be both. > >> > >> My idea is that if Calcite had a UNION type, I could declare the > columns as e.g. UNION(INT, ARRAY(INT)). > >> > >> Does this sound reasonable? Or is there a better way of handling this > situation using the current features of Calcite? > >> > >> Thanks. > >> - A > >> > >> > > > >
