jnturton commented on PR #2638:
URL: https://github.com/apache/drill/pull/2638#issuecomment-1246863598
Getting through UT proved to be a veritable warren of rabbit holes! Which
probably says good things about the UT.
--
This is an automated message from the Apache Git Service.
To respond
jnturton commented on PR #2638:
URL: https://github.com/apache/drill/pull/2638#issuecomment-1245043064
Many of the casts exhibited above do already work in Drill. What we get here
is the elimination of some obscure broken cases like sqrt('5') and what is
hopefully a more intelligible and ma
jnturton commented on PR #2638:
URL: https://github.com/apache/drill/pull/2638#issuecomment-1243628238
Turns out this particular one isn't possible without breaking other things
that need VARCHAR to go to INT before it goes to DATE.
```
apache drill> select date_diff('2022-09-08', '197
jnturton commented on PR #2638:
URL: https://github.com/apache/drill/pull/2638#issuecomment-1242077430
```
Apache Drill 2.0.0-SNAPSHOT
"Drill must go on."
apache drill> select true = 'TrUe';
EXPR$0 true
1 row selected (3.336 seconds)
apache drill> select true = 'false';
jnturton commented on PR #2638:
URL: https://github.com/apache/drill/pull/2638#issuecomment-1242025805
> > I wonder whether ResolverTypePrecedence should cache computed casting
costs, or whether that would be premature optimisation.
>
> Maybe make that a separate PR. In theory the who
jnturton commented on PR #2638:
URL: https://github.com/apache/drill/pull/2638#issuecomment-1242020822
> This is really a MAJOR usability improvement. Will it also be able to cast
`"true"` and `"false"` as boolean values? Likewise for:
>
> * True
>
> * TRUE
>
>
jnturton commented on PR #2638:
URL: https://github.com/apache/drill/pull/2638#issuecomment-1241991578
I wonder whether ResolverTypePrecedence should cache computed casting costs,
or whether that would be premature optimisation.
--
This is an automated message from the Apache Git Service.
jnturton commented on PR #2638:
URL: https://github.com/apache/drill/pull/2638#issuecomment-1240784918
> >
>
> That brings a tear to me eye!
A piece I haven't added is a cast function implementation going from BIT to
INT using the normal 0 = false, 1 = true correspondence to e
jnturton commented on PR #2638:
URL: https://github.com/apache/drill/pull/2638#issuecomment-1240777691
> Queries like that will work in MySQL and other RDBMS. In Drill I think
they won't fail, but the results are not what people expect. For cases like
this, would '2020-01-01' be automati
jnturton commented on PR #2638:
URL: https://github.com/apache/drill/pull/2638#issuecomment-1238561477
> @jnturton Do you think this should be included in the backport to stable?
My own thought is probably not since it changes the function matching
process and there isn't any clear bu
10 matches
Mail list logo
