chore: Do not include Parquet extension

[krlmlr]

.

[Tmonster]

Hmmm, I'm wondering how we could test this. Since the duckdb src hash won't always point to a release, auto-loading happens in a special way.

My experience has been that If the duckdb source is not a release, then you need to enable unsigned extensions and load them directly using their path. To test auto-loading in duckdb, I think we would need to checkout the most recent duckdb release and duckdb-r, run the vendor.sh, then run commands like

duckdb:::sql('call dbgen(sf=1)')
duckdb:::sql('export (select range as a from range(100)) to \'test.parquet\' (FORMAT PARQUET)'

Might require a separate GitHub action as well? I can spend some time on this today to see what it would look like

[Tmonster]

#4 (review)

Realizing this won't working right now as auto-loading will only be in the 0.9.0 release ( so potentially in 2 weeks). I can probably just write the tests to call Install {{extension}}; Load {{extension}} then in 2 weeks update the PR.

[Tmonster]

ok, so GitHub tests to make sure auto-loading extensions is kinda redundant. because the r client and the source can change, it's not guaranteed that the R package can build with a combination of the "bleeding edge" of duckdb-r and the latest release of duckdb.

What you would have to do is checkout the latest commit tags of both duckdb-r and duckdb, and then run a test for extensions. Because both repos will be releases, the R build should succeed, and the auto-loading should work. @hannes is there a release test script/process where I can testing of extension auto-loading in R?