Re: [discuss] Standardizing Naming Schemes for Language-Specific Configurations

We've run into this same issue in a number of cases previously and I think where we want to ideally go (in most cases) is language agnostic properties/values. For example, the property for `catalog-impl`

Re: [discuss] Standardizing Naming Schemes for Language-Specific Configurations

We formalized some of the configurations in the REST spec . Still, I would be reluctant to try to create an exhaustive list of configuration options since it will be tough to m

Re: [discuss] Standardizing Naming Schemes for Language-Specific Configurations

My initial comment on this is that neither Go nor Rust, to my knowledge, support dynamic loading in this way. So formalization of rs-, cpp- or go- prefixes like this wouldn't be useful in any meaningful way as they would need to be linked in ahead of time for it to work. There are probably very ha

Re: [discuss] Standardizing Naming Schemes for Language-Specific Configurations

Generally it makes sense to define separate language-specific configurations. I think we need to think about the following items: 1. Is it python-specific to add the prefix? Should Rust/Go be -rs/-go as the convention? 2. Which part of the spec is the best place to describe this? It seems that we

[discuss] Standardizing Naming Schemes for Language-Specific Configurations

Hi everyone, I’d like to open a discussion on the naming scheme for configuration parameters across different languages. While working on the LocationProvider implementation in PyIceberg (#1452 ), we encountered a challenge with naming configura