unsubscribe

2020-05-12 Thread 刘杰

Re: [DISCUSS] Resolve ambiguous parser rule between two "create table"s

2020-05-12 Thread Jungtaek Lim
Never mind, forget about the dead code. Turned out that reverting "via manual" can be very easily done - remove config and apply to the tests -> remove field -> remove the changes into docs. It was considered as non-trivial because we only consider about "git revert" but there's no strict rule to

Clarification on Spark code comments

2020-05-12 Thread Neerav Kumar
Hi I am new to the community so pardon me if my question is framed incorrectly. I was going through the Spark code base on GitHub and am confused with comment mentioned. In file

Re: [DISCUSS] Resolve ambiguous parser rule between two "create table"s

2020-05-12 Thread Jungtaek Lim
It's not only for end users, but also for us. Spark itself uses the config "true" and "false" in tests and it still brings confusion. We still have to deal with both situations. I'm wondering how long days it would be needed to revert it cleanly, but if we worry about the amount of code change

Re: [DISCUSS] Resolve ambiguous parser rule between two "create table"s

2020-05-12 Thread Jungtaek Lim
Before I forget, we'd better not forget to change the doc, as create table doc looks to represent current syntax which will be incorrect later. On Tue, May 12, 2020 at 5:32 PM Jungtaek Lim wrote: > It's not only for end users, but also for us. Spark itself uses the config > "true" and "false"

unsubscribe

2020-05-12 Thread Kiran B
Thank you, Kiran,

Re: [VOTE] Release Spark 2.4.6 (RC1)

2020-05-12 Thread Yuanjian Li
Thanks Holden and Dongjoon for the help! The bugfix for SPARK-31663 is ready for review, hope it can be picked up in 2.4.7 if possible. https://github.com/apache/spark/pull/28501 Best, Yuanjian Takeshi Yamamuro 于2020年5月11日周一 上午9:03写道: > I checked on my MacOS env; all the tests > with `-Pyarn

Re: [VOTE] Release Spark 2.4.6 (RC1)

2020-05-12 Thread Holden Karau
Thanks. The 2.4.6 RC1 vote fails because we don’t have enough binding +1s, I’ll start a new RC once 31663 is merged or next week whichever is first. On Tue, May 12, 2020 at 7:28 AM Yuanjian Li wrote: > Thanks Holden and Dongjoon for the help! > The bugfix for SPARK-31663 is ready for review,

Re: [VOTE] Release Spark 2.4.6 (RC1)

2020-05-12 Thread Prashant Sharma
Hi Holden, I am +1 on this release, the fix for SPARK-31663 can make it to next release as well. Thanks, On Tue, May 12, 2020 at 8:09 PM Holden Karau wrote: > Thanks. The 2.4.6 RC1 vote fails because we don’t have enough binding +1s, > I’ll start a new RC once 31663 is merged or next week

[Datasource V2] Exception Handling for Catalogs - Naming Suggestions

2020-05-12 Thread Russell Spitzer
Currently the way some actions work, we receive an error during analysis phase. For example, doing a "SELECT * FROM non_existent_table" will return an analysis exception as the NoSuchTableException is captured and replaced. Other actions like the "ShowNamespaceExec" call catalog methods directly

Re: [DISCUSS] Resolve ambiguous parser rule between two "create table"s

2020-05-12 Thread Ryan Blue
+1 for the approach Jungtaek suggests. That will avoid needing to support behavior that is not well understood with minimal changes. On Tue, May 12, 2020 at 1:45 AM Jungtaek Lim wrote: > Before I forget, we'd better not forget to change the doc, as create table > doc looks to represent current

Re: [DISCUSS] Resolve ambiguous parser rule between two "create table"s

2020-05-12 Thread Russell Spitzer
I think that the dead code approach, while a bit unpalatable and worse than reverting, is probably better than leaving the parameter (even if it is hidden) On Tue, May 12, 2020 at 12:46 PM Ryan Blue wrote: > +1 for the approach Jungtaek suggests. That will avoid needing to support > behavior