feat(r/sedonadb): Add SQL translation for nested field

[yutannihilation]

Fix #1169

Translate an R expression a$b as SQL get_field(a, 'b').

library(sdplyr)
#> ── Attaching sdplyr packages ───────────────────────────────────── 0.4.0.9000 ──
#> ✔ sedonadb  0.4.0.9000
#> ✔ sedonafns 0.4.0.9000
#> ✔ dplyr     1.2.0

df <- sedonadb::sd_sql(
  "SELECT named_struct('bar', named_struct('baz', 1)) AS foo"
)

df |> 
  filter(foo$bar$baz > 0) |>
  transmute(value = foo$bar$baz) |>
  collect()
#> # A tibble: 1 × 1
#>   value
#>   <dbl>
#> 1     1

^{Created on 2026-08-16 with reprex v2.1.1}

I was thinking the implementation would be simpler than this, but it seems sd_eval_expr_inner() needs to be executed recursively in order to support a mixed case like this.

df |> 
  transmute(value = .fns$get_field(foo, 'bar')$baz)

[paleolimbot]

Thank you!

For what it's worth I did go with a "custom evaluation" approach which made this a little awkward, and possibly I should have started with a "manipulate the environment and mask and use regular evaluation" approach (like arrow and maybe others).

[yutannihilation]

Thanks!

Btw, I was wondering if there's some reason not to build on dbplyr. Maybe something related to interoperability with Arrow...?

[paleolimbot]

At the time I started this there was no good integration with ADBC which would be the natural way to execute the SQL (the latest dbplyr does, I think). Other than that, it seemed like a bit of a waste to compile expressions into SQL and then parse the SQL immediately. DataFusion has a great logical plan/expression API, and this seemed closest to duckplyr so I mostly followed what they did there.

It's probably easy to prototype this and I'm happy to add it as an option if it makes things easier!

[yutannihilation]

Other than that, it seemed like a bit of a waste to compile expressions into SQL and then parse the SQL immediately. DataFusion has a great logical plan/expression API

Ah, thanks, this makes sense to me!