Hello Robert, I agree with your point that, strictly speaking, this would be a breaking REST API change. If the case-insensitivity is baked into a future API specification, it would eliminate the need for additional logic to handle it elsewhere.
I have a question about the API evolution process: - How is the API evolved? - Is there a specific working group dedicated to API changes? - Does this process follow a predefined cadence? If we decide to go this route, it would be helpful to ensure this change is on the radar of the right people so it does not get overlooked. Best regards, Innocent On Tue, Jan 6, 2026 at 4:18 AM Robert Stupp <[email protected]> wrote: > Hi all, > > Thanks for taking a stab on this issue and the constructive discussion! > > Very strictly speaking this would be a breaking REST API change. > I propose to consider making those technical identifiers > case-insensitive in a future version of the REST API. > > Robert > > On Mon, Jan 5, 2026 at 6:32 PM Innocent Djiofack <[email protected]> > wrote: > > > > Hello Dmitri, > > > > Thanks for your prompt reply. > > > > I understand your point about the added complexity in JSON serialization > > and agree that, from a user perspective, it is not a major hindrance to > > productivity. I am comfortable with either outcome and will be happy to > > follow the direction the community decides to take on this issue. > > > > Best regards, > > Innocent > > > > On Mon, Jan 5, 2026 at 10:20 AM Dmitri Bourlatchkov <[email protected]> > > wrote: > > > > > Hi Innocent, > > > > > > I appreciate your involvement in this project and your contribution > towards > > > [996]! > > > > > > You PR [3349] looks correct and concise. > > > > > > However, it does introduce extra complexity into the serialization of > > > Polaris data over JSON. Given that the case insensitivity consents in > [996] > > > are about technical type IDs, I personally do not think adding > complexity > > > in JSON (de-)serialization in this case is worth the feature. > > > > > > Assuming existing error messages on type name mismatches are clear, I > think > > > it should be fairly straight-forward for clients / users to use upper > case > > > type IDs. > > > > > > If other people think that having case insensitive type IDs is still > worth > > > the extra code complexity, PR [3349] looks good to me from the > technical > > > perspective. > > > > > > [996] https://github.com/apache/polaris/issues/996 > > > > > > [3349] https://github.com/apache/polaris/pull/3349 > > > > > > Cheers, > > > Dmitri. > > > > > > On Fri, Jan 2, 2026 at 12:50 AM Innocent Djiofack < > [email protected]> > > > wrote: > > > > > > > Hello, > > > > My name is Innocent. I am a new apache Polaris user who is strongly > > > > interested in contributing to the code base. I have been looking at > #996 > > > > <https://github.com/apache/polaris/issues/996> and given the back > and > > > > forth > > > > on the issue as well as the guidance from Dmitry, I thought it would > be a > > > > good idea to start this thread to align on what should be done. > > > > > > > > As a quick refresher, the issue is that storage type is not case > > > sensitive. > > > > Attempting to create catalogs with storage type different `file` > instead > > > of > > > > `FILE` or `s3` instead of `S3` will fail. Other operations requiring > the > > > > storage type will also fail. On the user side, once the issue is > > > detected > > > > it is generally quite easy to fix. However, user experience will be > much > > > > improved if users don't have to worry about such details, so I think > > > making > > > > storage type case insensitive would be an improvement. > > > > > > > > Before I get into how we would want to do it, I would like to gather > > > > opinions on the matter before I invest more time into looking at how > the > > > > change would look like. > > > > > > > > Thank you for having me in the community! > > > > > > > >
