D:\a\duckdb\duckdb\src\main\capi\logical_types-c.cpp(216,45): error C2065: 'string_t': undeclared identifier [D:\a\duckdb\duckdb\src\main\capi\duckdb_main_capi.vcxproj]
D:\a\duckdb\duckdb\src\main\capi\logical_types-c.cpp(216,37): error C2672: 'duckdb::FlatVector::GetData': no matching overloaded function found [D:\a\duckdb\duckdb\src\main\capi\duckdb_main_capi.vcxproj]
  D:\a\duckdb\duckdb\src\include\duckdb\common\types\vector.hpp(329,19):
  could be 'T *duckdb::FlatVector::GetData(duckdb::Vector &)'
  	D:\a\duckdb\duckdb\src\main\capi\logical_types-c.cpp(216,45):
  	'duckdb::FlatVector::GetData': invalid template argument for 'T', type expected
  D:\a\duckdb\duckdb\src\include\duckdb\common\types\vector.hpp(325,25):
  or       'const T *duckdb::FlatVector::GetData(const duckdb::Vector &)'
  	D:\a\duckdb\duckdb\src\main\capi\logical_types-c.cpp(216,45):
  	'duckdb::FlatVector::GetData': invalid template argument for 'T', type expected
  
D:\a\duckdb\duckdb\src\main\capi\logical_types-c.cpp(221,16): error C3536: 'strings': cannot be used before it is initialized [D:\a\duckdb\duckdb\src\main\capi\duckdb_main_capi.vcxproj]
D:\a\duckdb\duckdb\src\main\capi\logical_types-c.cpp(221,25): error C2109: subscript requires array or pointer type [D:\a\duckdb\duckdb\src\main\capi\duckdb_main_capi.vcxproj]
D:\a\duckdb\duckdb\src\main\capi\logical_types-c.cpp(222,47): error C3536: 'value': cannot be used before it is initialized [D:\a\duckdb\duckdb\src\main\capi\duckdb_main_capi.vcxproj]

seems to missing an include for duckdb/common/types/string_type.hpp

I don't understand the build. I was able to run the tests and build it. But I changed string_t to duckdb::string_t which duckdb_create_enum_type in the hope that this is what was needed.

Thanks for the PR! Can't the same behavior be accomplished by using duckdb_enum_dictionary_size and duckdb_enum_dictionary_value?

In general we want to keep the C API lean and not add functions unnecessarily. It is not meant to be nice to use stand-alone but rather meant as a building block for other APIs, so if the functionality is available elsewhere adding extra functions is not desirable.

@Mytherin What about adding a function that takes an enum member name and returns its numeric value? Similar to duckdb_enum_dictionary_value but reversed. Sure, it can be done with duckdb_enum_dictionary_size and duckdb_enum_dictionary_value but I think it's useful to have a dedicated function instead of calling duckdb_enum_dictionary_value in a loop.

Sure, that makes sense

You know...I didn't want to couple the size of the dictionary to the underlying enum value. I figured the two might not always be tightly coupled: what if you were allowed to drop an enum value, then you'd have a hole. But I realize that might implementation has the same baked-in coupling by depending on the index of the array...So sorry.

No need to apologize.

The logical type contains the type after catalog resolution, so a drop/create of the enum value would not affect it as we are not going back to the catalog between these steps. As such that scenario will work correctly in both cases.