this post was submitted on 25 Aug 2024
51 points (90.5% liked)

Programming

17366 readers
398 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 1 year ago
MODERATORS
snowe@programming.dev
Ategon@programming.dev
MaungaHikoi@lemmy.nz
51
SQL Has Problems. We Can Fix Them: Pipe Syntax In SQL (research.google)
submitted 2 months ago by LPThinker@lemmy.world to c/programming@programming.dev
25 comments fedilink hide all child comments
 

Really intriguing article about a SQL syntax extension that has apparently already been trialed at Google.

As someone who works with SQL for hours every week, this makes me hopeful for potential improvements, although the likelihood of any changes to SQL arriving in my sector before I retire seems slim.

you are viewing a single comment's thread
view the rest of the comments
[–] xmunk@sh.itjust.works 6 points 2 months ago (2 children)

The reorganization of statements is excellent but the pipe operator itself is unnecessary and annoying. It'd be far better to just rearrange the clauses and call it a day, relying on the keywords that are still present to signify clause termination...

Especially once we get into subqueries and CTES, I never want to write:

|> LEFT JOIN |> FROM foo |> GROUP BY clusterid |> SELECT clusterid, COUNT(*)
      ON cluster.id = foo.clusterid

And I'm also not splitting out a trivial subselect like that into four lines because I respect my reader.

[–] tal@lemmy.today 4 points 2 months ago

I find dplyr in R to be pretty reasonable.

https://cran.r-project.org/web/packages/dplyr/vignettes/dplyr.html

I don't know if that's what the article is referring to by "other data languages".

[–] frezik@midwest.social 2 points 2 months ago (1 children)

What about respecting the reader of the diff when there's a change in the middle?

[–] xmunk@sh.itjust.works 2 points 2 months ago (1 children)

If this is something likely to change I'd space it out - but mid-line diffs are usually pretty readable in most clients.

As always, expression should cater to readability and shouldn't be limited by syntax rules.

[–] frezik@midwest.social 2 points 2 months ago* (last edited 2 months ago)

No matter which tool you're using, this:

- |> LEFT JOIN |> FROM foo |> GROUP BY clusterid |> SELECT clusterid, COUNT(*)
+ |> LEFT JOIN |> FROM foobar |> GROUP BY clusterid |> SELECT clusterid, COUNT(*)
      ON cluster.id = foo.clusterid

Is always less readable than:

  |> LEFT JOIN 
- |> FROM foo 
+ |> FROM foobar
  |> GROUP BY clusterid 
  |> SELECT clusterid, COUNT(*)
      ON cluster.id = foo.clusterid

And this isn't even the worst example I've seen. That would be a file that had a bug due to duplicated entries in a list, and it became very obvious as soon as I converted it to something akin to the second version.