Agreed that this is a needed consistency correction and should be benign.
I think our first top level project release, with SQL++ and other goodies,
should be the point beyond which such changes are no longer okay I
think this is "last call" for data-impacting changes. Henceforth we'll
need t
Thanks for the clarification.
Best,
Taewoo
On Tue, Oct 18, 2016 at 9:12 AM, Yingyi Bu wrote:
> >> I'm just worried about the backward compatibility.
> >> If we change the definition (before:int for int64, after:int for integer
> >> (int32)) and outside users that Mike mentioned did not have num
>> I'm just worried about the backward compatibility.
>> If we change the definition (before:int for int64, after:int for integer
>> (int32)) and outside users that Mike mentioned did not have numbers
greater
>> than INT32 range, I think it's OK.
As I said, if they have created a dataset using the
Taewoo,
>> So, can we use "int" for "bigint" to be consistent?
That's not what other SQL systems do. We probably don't want to create
new conventions (or surprises) in this area.
Just FYI.
Hive:
https://cwiki.apache.org/confluence/display/Hive/LanguageManual+Types#LanguageManual
I understood that other SQL based systems have int and bigint. What we used
was "int" for "int64". I'm just worried about the backward compatibility.
If we change the definition (before:int for int64, after:int for integer
(int32)) and outside users that Mike mentioned did not have numbers greater
So, can we use "int" for "bigint" to be consistent?
Best,
Taewoo
On Tue, Oct 18, 2016 at 7:34 AM, Yingyi Bu wrote:
> >>Actually I think Taewoo is right about having supported int as an int64
> >>synonym in ADM.
>
> Ahh, just checked an old version and you're right!
>
> >> But I think the revise
>>Actually I think Taewoo is right about having supported int as an int64
>>synonym in ADM.
Ahh, just checked an old version and you're right!
>> But I think the revised 101 examples used int, no?
Yes, they use int.
>> We should just check so we know if we need to warn them when
>> we release...
Actually I think Taewoo is right about having supported int as an int64
synonym in ADM. However, apparently this change didn't break any tests, so
we probably didn't have anything whose outputs were changed. But I think
the revised 101 examples used int, no? Not sure if any of our users had
foll
This is the change that changes "record" to "object".
https://asterix-gerrit.ics.uci.edu/#/c/1295/
The existing record functions will still work.
If anyone thinks that the change breaks the current use case, please let me
know.
Best,
Yingyi
On Mon, Oct 17, 2016 at 10:26 PM, Yingyi Bu wrote:
>> We used int for the abbreviation
>> for INT64 (I assume that is now bigint?) type. Now, INT is an
abbreviation
>> for INT32?
We didn't have "int" as a type name.
A constant integer value by default was an int64. That's unchanged.
Now, a constant integer value by default is a bigint.
>> Aren't
10 matches
Mail list logo
