Thanks for the PR! Great find.

If I understand correctly the problem is that CreateAPIv0 is called in a static method (GetAPI) - when elsewhere we get a function pointer to that static method (in CreateAccessStruct) - likely preventing that call from being optimized out - causing the entire C API to always be statically linked in/never pruned.

Given that this is the problem - I wonder if we can simplify this solution. Do we need to hand out pointers to the struct that resides in the DatabaseInstance, or could we also just make a copy? That would avoid the need for locking and avoids introducing additional unnecessary lifetime problems.

@Mytherin do you mean like this? (7edb53d)

I think the convention should be that extensions copy the struct over into some global variable anyway, at least thats what the macro's in the duckdb_extensions.h do anyway. However I could see how leaving the pointers valid could results in people incorrectly assuming they are always valid and lifetime issues arising. To resolve that I have made an extra copy that ensures the pointer to the function pointer struct that the extension sees during initialization will only be valid during the initialization forcing the extension to copy it.

@Mytherin: I think this is ready

Results (as per the added check) are:

- checking 'tpch': old size=41925566, new_size=14761342
- checking 'json': old size=41906006, new_size=34334838
- checking 'parquet': old size=41953918, new_size= 36586230
- checking 'tpcds': old size=41962926, new_size=16051550

1 sec, I will try to refactor it so that we don't need to store the struct in the databaseinstance.

I think either through using a virtual method or storing the function pointer to the CreateAPIv0() in the databaseinstance that should work

@Mytherin Tried making a virtual DatabaseInstance::GetExtensionAPIV0() method, but that resulting in some weird crashes on loading extensions.

Went with the function pointer approach, which seems clean enough to me

That's cleaner - but I wonder if this does not also work? In that case we would not need to store anything in the database instance.

const duckdb_ext_api_v0 DatabaseInstance::GetExtensionAPIV0() {
	return CreateAPIv0();
}

No that will get the size right back up where it was

Alright, let's get this in as-is then. Thanks!

Let's do a final double check for the binary sizes before merge. I checked locally, but better safe than sorry

link to relevant ci job

sizes seem all good:

 - checking 'tpch': old size=41913902, new_size=14765854
 - checking 'json': old size=41894342, new_size=34335206
 - checking 'parquet': old size=41942070, new_size=36578406
 - checking 'tpcds': old size=41951254, new_size=16051966