Autoload of ICU extension does not work

[al-obrien]

Issue description

Both on version 1.4.2 and the latest 1.5.1, duckdb from an R session on RHEL8 does not appear to have the important icu extension loaded.

Others (#1084) have referenced this previously but it appears to be non functional in this situation.

These are the duckdb extension settings:

This is confusing as the official docs have a reference to this being bundled:

Session Info

> sessionInfo()
R version 4.4.1 (2024-06-14)
Platform: x86_64-pc-linux-gnu
Running under: Red Hat Enterprise Linux 8.10 (Ootpa)

Matrix products: default
BLAS/LAPACK: /usr/lib64/libopenblasp-r0.3.15.so;  LAPACK version 3.9.0

locale:
 [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C               LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8     LC_MONETARY=en_US.UTF-8   
 [6] LC_MESSAGES=en_US.UTF-8    LC_PAPER=en_US.UTF-8       LC_NAME=C                  LC_ADDRESS=C               LC_TELEPHONE=C            
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C       

time zone: America/Edmonton
tzcode source: system (glibc)

attached base packages:
[1] stats     graphics  grDevices datasets  utils     methods   base     

other attached packages:
 [1] data.table_1.17.8  qs2_0.1.6          fs_1.6.6           AHRtools_1.2.4     AHRio_0.7.2        odbc_1.6.3         DBI_1.2.3         
 [8] stringr_1.6.0      glue_1.8.0         lubridate_1.9.4    crew_1.3.0         tarchetypes_0.13.2 targets_1.11.4    

loaded via a namespace (and not attached):
 [1] config_0.3.2          utf8_1.2.6            generics_0.1.4        renv_1.1.2            stringi_1.8.7         hms_1.1.4            
 [7] magrittr_2.0.4        evaluate_1.0.5        timechange_0.3.0      blob_1.2.4            processx_3.8.6        backports_1.5.0      
[13] secretbase_1.0.5      ps_1.9.1              promises_1.5.0        codetools_0.2-20      collections_0.3.9     duckdb_1.5.1         
[19] cli_3.6.5             crayon_1.5.3          rlang_1.1.6           bit64_4.6.0-1         withr_3.0.2           yaml_2.3.10          
[25] otel_0.2.0            tools_4.4.1           parallel_4.4.1        dplyr_1.1.4           nanonext_1.7.2        base64url_1.4        
[31] vctrs_0.6.5           R6_2.6.1              lifecycle_1.0.4       stringfish_0.17.0     bit_4.6.0             pkgconfig_2.0.3      
[37] callr_3.7.6           RcppParallel_5.1.11-1 pillar_1.11.1         later_1.4.4           Rcpp_1.1.0            xfun_0.54            
[43] tibble_3.3.0          tidyselect_1.2.1      rstudioapi_0.17.1     knitr_1.50            mirai_2.5.2           igraph_2.2.1         
[49] compiler_4.4.1        prettyunits_1.2.0    

[krlmlr]

Thanks. What happens when you run

duckdb::sql_exec("INSTALL icu")

?

[al-obrien]

The following occurs.

duckdb::sql_exec("INSTALL icu")
[1] 0  

dbGetQuery(mycon, 'SELECT today()')
     today()
1 2026-03-31

Does this mean the icu extension isnt bundled? Would this mean every user on a team accessing the database would need this added step?

[krlmlr]

I'm afraid yes. Once for each duckdb version. The docs might need an update.

We're already very close to the limit of what CRAN allows in terms of package size. Bundling icu would break that limit.

[al-obrien]

That's unfortunate. I assume this step would include users that only read from duckdb that makes use of icu?

I wonder if CRAN would allow an exception for such a common utility... I assume that has already been explored. It seems easy enough to run that code suggested, but maybe theres a list of extensions commonly used that a duckdb-r helper function could assist with?

In any case, I know I would have found it useful if extension details were added to some of the setup steps in the package website, especially since it differs from what I read from the python implementation: https://r.duckdb.org/index.html#building

[krlmlr]

Thanks. I don't understand the first question and the proposal in the second paragraph.

I agree the docs can be improved. Happy to review a PR here, upstream docs would be reviewed by the DuckDB team but I can also help.

[al-obrien]

Ill clarify the two pieces that you said were unclear:

1. If someone creates/writes to a database with duckdb, they will need to install icu before they can create any tables that need icu functionality. However, do readers also require icu installed before they can query a table? For example, a CREATE TABLE statement has a default value for a column as date_created DATE DEFAULT today(). I assume this would not impact readers of this table unless they start to use the icu functions directly?
2. I assume you mean the helper function referenced. This could be something like duckdb::install_common_ext(), with some default set of extensions given as input