On Fri, May 15, 2020 at 10:33 PM Reuven Lax wrote:
>
>
> On Fri, May 15, 2020 at 8:10 PM Kenneth Knowles wrote:
>
>>
>>
>> On Fri, May 15, 2020 at 5:25 PM Brian Hulette
>> wrote:
>>
>>> After thinking about this more I've softened on it some, but I'm still a
>>> little wary. I like Kenn's
On Fri, May 15, 2020 at 8:10 PM Kenneth Knowles wrote:
>
>
> On Fri, May 15, 2020 at 5:25 PM Brian Hulette wrote:
>
>> After thinking about this more I've softened on it some, but I'm still a
>> little wary. I like Kenn's suggestion:
>>
>> > - it is OK to convert known logical types like
On Fri, May 15, 2020 at 5:25 PM Brian Hulette wrote:
> After thinking about this more I've softened on it some, but I'm still a
> little wary. I like Kenn's suggestion:
>
> > - it is OK to convert known logical types like MillisInstant or
> NanosInstant to a ZetaSQL "TIMESTAMP" or Calcite SQL
On Fri, May 15, 2020 at 5:25 PM Brian Hulette wrote:
> After thinking about this more I've softened on it some, but I'm still a
> little wary. I like Kenn's suggestion:
>
> > - it is OK to convert known logical types like MillisInstant or
> NanosInstant to a ZetaSQL "TIMESTAMP" or Calcite SQL
After thinking about this more I've softened on it some, but I'm still a
little wary. I like Kenn's suggestion:
> - it is OK to convert known logical types like MillisInstant or
NanosInstant to a ZetaSQL "TIMESTAMP" or Calcite SQL "TIMESTAMP WITH LOCAL
TIME ZONE"
> - it is OK to convert unknown
I would not describe the base type as the "wire type." If that were true,
then the only base type we should support should be byte array.
My simple point is that this is no different than normal schema fields. You
will find many normal schemas containing data encoded into other field
types. You
My understanding is that the base type is effectively the wire format at
the type, where the logical type is the in-memory representation for Java.
For org.joda.time.Instant, this is just a wrapper around the underlying
Long. However for the Date logical type, the LocalDate type has struct as
the
On Fri, Apr 24, 2020 at 11:56 AM Brian Hulette wrote:
> When we created the portable representation of schemas last summer we
> intentionally did not include DATETIME as a primitive type [1], even though
> it already existed as a primitive type in Java [2]. There seemed to be
> consensus around
This seems like a good idea. This stuff is all still marked "experimental"
for exactly this reason. This is a case where the name fits perfectly. Both
SQL and schemas are new and still working towards a form that can be
supported indefinitely without layers of workarounds that will never
quiesce.
When we created the portable representation of schemas last summer we
intentionally did not include DATETIME as a primitive type [1], even though
it already existed as a primitive type in Java [2]. There seemed to be
consensus around a couple of points: 1) At the very least DATETIME is a
poor name
10 matches
Mail list logo