gene-db closed pull request #47186: [SPARK-48784][SQL] Add ::: syntax as a
shorthand for try_cast
URL: https://github.com/apache/spark/pull/47186
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the
cloud-fan commented on PR #47186:
URL: https://github.com/apache/spark/pull/47186#issuecomment-2221936907
@dongjoon-hyun The parser extension is known to be cumbersome. We need to
provide a fully functional ANTLR parser which will be run before Spark's own
parser and fallback to Spark's par
srielau commented on PR #47186:
URL: https://github.com/apache/spark/pull/47186#issuecomment-2220843355
To bypass the worry about scala: How about `?::` It is arguably more
descriptive. And a leading `?` could be used for other operations like ` a ?/
b` (instead of try_divide(a, b))
--
T
dongjoon-hyun commented on PR #47186:
URL: https://github.com/apache/spark/pull/47186#issuecomment-2220778827
> Do you mean adding a config to fail this syntax by default?
No~ I meant to provide this as a built-in extension to enable this syntax.
And, by default, the extension and thi
cloud-fan commented on PR #47186:
URL: https://github.com/apache/spark/pull/47186#issuecomment-2220389309
Do you mean adding a config to fail this syntax by default? BTW if people
write `:::` today they will get ANTLR parser errors.
--
This is an automated message from the Apache Git Serv
dongjoon-hyun commented on PR #47186:
URL: https://github.com/apache/spark/pull/47186#issuecomment-2219946843
It's good to know. If we need this in the Spark codebase, please provide a
way for the community to free from this syntax in production environments. I
believe that can be achievabl
cloud-fan commented on PR #47186:
URL: https://github.com/apache/spark/pull/47186#issuecomment-2216331538
> ... because Spark is a platform built upon Scala
Spark has a lot more users on Python and SQL, I don't really buy it. And we
already have `::`. The value of `:::` is the same as
dongjoon-hyun commented on PR #47186:
URL: https://github.com/apache/spark/pull/47186#issuecomment-2216315458
To @cloud-fan , this PR is only adding a syntactic sugar, isn't it?
> We should have them in Spark out of the box if the value is well
justified.
For Iceberg `CALL` comman
yaooqinn commented on PR #47186:
URL: https://github.com/apache/spark/pull/47186#issuecomment-2216253309
I also cast my vote against this because Spark is a platform built upon
Scala, in which `:::` means the concatenation of two lists. So I don't see the
value of adding this, but it would
srielau commented on PR #47186:
URL: https://github.com/apache/spark/pull/47186#issuecomment-2216246823
We are proposing a non-ANSI (`:::`) extension to a non-ANSI expression
(`try_cast`) mimicking a non-ANSI extension (`::`) to an ANSI expression
(`cast`). All motivated by ease of use for
cloud-fan commented on PR #47186:
URL: https://github.com/apache/spark/pull/47186#issuecomment-2215920265
@dongjoon-hyun It's like why we add stored procedure into Spark. Iceberg can
use extension APIs to implement the CALL command, but it's better to have it in
Spark out of the box for eas
dongjoon-hyun commented on PR #47186:
URL: https://github.com/apache/spark/pull/47186#issuecomment-2215873682
> @dongjoon-hyun Many databases have extensions over the SQL standard and so
does Spark. I don't think delaying the discussion helps (BTW there is another
one ongoing: #46707). We s
cloud-fan commented on PR #47186:
URL: https://github.com/apache/spark/pull/47186#issuecomment-2215840875
@dongjoon-hyun Many databases have extensions over the SQL standard and so
does Spark. I don't think delaying the discussion helps (BTW there is another
one ongoing: https://github.com/
mkaravel commented on PR #47186:
URL: https://github.com/apache/spark/pull/47186#issuecomment-2215510622
> It looks very uncommon and incurs a cognitive cost for users. Also cc
@dongjoon-hyun
When something new is added in a language there is naturally a cognitive
overhead to adapt t
srielau commented on PR #47186:
URL: https://github.com/apache/spark/pull/47186#issuecomment-2214573156
> We need to be careful when adding new Spark-only SQL syntaxes, but it
doesn't mean Spark can't be the first one to do innovation.
>
> It seems to be a natural extension of the exi
mkaravel commented on PR #47186:
URL: https://github.com/apache/spark/pull/47186#issuecomment-2214443368
When Redshift introduced SUPER they faced the same issue, which is basically
the clunkiness of writing an effective query in the presence of the SUPER data
type, which (as the VARIANT ty
cloud-fan commented on PR #47186:
URL: https://github.com/apache/spark/pull/47186#issuecomment-2214207514
We need to be careful when adding new Spark-only SQL syntaxes, but it
doesn't mean Spark can't be the first one to do innovation.
It seems to be a natural extension of the existin
srielau commented on PR #47186:
URL: https://github.com/apache/spark/pull/47186#issuecomment-2213069069
> I'm also reluctant like @yaooqinn 's comment.
>
> Could you summarize the status of other DBMS in the PR description first
for further discussion?
As noted above SparkSQL w
dongjoon-hyun commented on PR #47186:
URL: https://github.com/apache/spark/pull/47186#issuecomment-2211415897
I'm also reluctant like @yaooqinn 's comment.
Could you summarize the status of other DBMS in the PR description first for
further discussion?
--
This is an automated messa
srielau commented on PR #47186:
URL: https://github.com/apache/spark/pull/47186#issuecomment-2211412434
> It looks very uncommon and incurs a cognitive cost for users. Also cc
@dongjoon-hyun
It is uncommon because it is new.
Note that other DBMS add short hands as well.
The firs
yaooqinn commented on PR #47186:
URL: https://github.com/apache/spark/pull/47186#issuecomment-2204987052
It looks very uncommon and incurs a cognitive cost for users. Also cc
@dongjoon-hyun
--
This is an automated message from the Apache Git Service.
To respond to the message, please log
gene-db opened a new pull request, #47186:
URL: https://github.com/apache/spark/pull/47186
### What changes were proposed in this pull request?
Add the `:::` (triple colon) as syntactic sugar for `try_cast`.
### Why are the changes needed?
This syntactic sugar makes it ea
22 matches
Mail list logo