This plan for evolving the TRIM function to be more standards compliant
sounds much better to me than the original change to just switch the order.
It pushes users in the right direction and cleans up our tech debt without
silently breaking existing workloads. It means that programs won't return
Yes, right. We need to choose the best way case by case.
The following level of `Runtime warning` also sounds reasonable to me.
> Maybe we should only log the warning once per Spark application.
Bests,
Dongjoon.
On Tue, Feb 18, 2020 at 1:13 AM Wenchen Fan wrote:
> I don't know what's the best
I don't know what's the best way to deprecate an SQL function. Runtime
warning can be annoying if it keeps coming out. Maybe we should only log
the warning once per Spark application.
On Tue, Feb 18, 2020 at 3:45 PM Dongjoon Hyun
wrote:
> Thank you for feedback, Wenchen, Maxim, and Takeshi.
>
>
Thank you for feedback, Wenchen, Maxim, and Takeshi.
1. "we would also promote the SQL standard TRIM syntax"
2. "we could output a warning with a notice about the order of
parameters"
3. "it looks nice to make these (two parameters) trim functions
unrecommended in future releases"
The revert looks fine to me for keeping the compatibility.
Also, I think the different orders between the systems easily lead to
mistakes, so
, as Wenchen suggested, it looks nice to make these (two parameters) trim
functions
unrecommended in future releases:
Also if we look at possible combination of trim parameters:
1. foldable srcStr + foldable trimStr
2. foldable srcStr + non-foldable trimStr
3. non-foldable srcStr + foldable trimStr
4. non-foldable srcStr + non-foldable trimStr
The case # 2 seems a rare case, and # 3 is probably the most common
It's unfortunate that we don't have a clear document to talk about breaking
changes (I'm working on it BTW). I believe the general guidance is: *avoid
breaking changes unless we have to*. For example, the previous result was
so broken that we have to fix it, moving to Scala 2.12 makes us have to
Please note that the context if TRIM/LTRIM/RTRIM with two-parameters and
TRIM(trimStr FROM str) syntax.
This thread is irrelevant to one-parameter TRIM/LTRIM/RTRIM.
On Fri, Feb 14, 2020 at 11:35 AM Dongjoon Hyun
wrote:
> Hi, All.
>
> I'm sending this email because the Apache Spark committers
Hi, All.
I'm sending this email because the Apache Spark committers had better have
a consistent point of views for the upcoming PRs. And, the community policy
is the way to lead the community members transparently and clearly for a
long term good.
First of all, I want to emphasize that, like
