On Using case insensitive storage type names.

[Innocent Djiofack <ki...@gmail.com>]

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!

Re: On Using case insensitive storage type names.

[Innocent Djiofack <ki...@gmail.com>]

Hi all,
Thank you for the suggestion to investigate ACCEPT_CASE_INSENSITIVE_ENUMS
however, I came to the conclusion that it would not work because
storageType in particular (Not sure about other enums) is bound to a type
and not a simple enum.
So the approach that could work would be to have a custom TypeIdResolver,
however this will have to be done on a case by case basis which is
something that we do not desire.
We could definitely make the change more hostlically at spec level but I
have hard times reasoning about the safety aspects of the change mostly
because it seems to have a much larger blast radius. It is also not clear
to me if we would intentionally break any of Polaris dependencies.

On Wed, Jan 7, 2026 at 4:07 AM Robert Stupp <sn...@snazy.de> wrote:

> Yes, Jackson has a feature toggle for this behavior.
>
> The breaking change would happen, as a newer client would break
> against an older server using the same spec version.
>
> Technically we have a lot of mapper instances floating around in
> Polaris, in production and even more in test code.
>
> The bigger issue is that the same (relevant) mapper instances are also
> used for other APIs like the Iceberg one.
>
> On Wed, Jan 7, 2026 at 11:43 AM Alexandre Dutra <ad...@apache.org> wrote:
> >
> > Hi all,
> >
> > First off, thank you, Innocent, for the recent PR [3349]!
> >
> > I've reviewed it and noted that it specifically special-cases the
> > StorageConfigInfo enum for deserialization. Drawing on the discussion
> > in [996], I believe we should adopt a more consistent approach: either
> > all enums should be deserialized in a case-insensitive manner, or none
> > should. Special-casing StorageConfigInfo feels unnecessarily
> > complicated.
> >
> > I therefore recommend we investigate using Jackson's
> > ACCEPT_CASE_INSENSITIVE_ENUMS Mapper feature [1] as a cleaner, more
> > consistent solution.
> >
> > Regarding the REST API: I am questioning whether this change would be
> > a breaking one. Existing clients should continue to function as
> > expected. The only potential failure scenario I can imagine is a
> > client intentionally sending an incorrect enum name and relying on it
> > to fail, which seems unlikely. Therefore, a formal REST API
> > specification change may not be necessary. What do others think?
> >
> > Thanks,
> > Alex
> >
> > [1]:
> https://www.javadoc.io/doc/com.fasterxml.jackson.core/jackson-databind/latest/com/fasterxml/jackson/databind/MapperFeature.html#ACCEPT_CASE_INSENSITIVE_ENUMS
> > [996]: https://github.com/apache/polaris/issues/996
> > [3349]: https://github.com/apache/polaris/pull/3349
> >
> > On Tue, Jan 6, 2026 at 9:30 PM Dmitri Bourlatchkov
> > <dm...@dremio.com> wrote:
> > >
> > > Hi Innocent,
> > >
> > > The most formal evolution doc we have is this:
> > > https://polaris.apache.org/in-dev/unreleased/evolution/
> > >
> > > There is no working group. API changes are simply expected to be
> discussed
> > > on `dev`.
> > >
> > > Cheers,
> > > Dmitri.
> > >
> > > On Tue, Jan 6, 2026 at 3:25 PM Innocent Djiofack <kidjiofack@gmail.com
> >
> > > wrote:
> > >
> > > > 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 <sn...@snazy.de> 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 <
> kidjiofack@gmail.com>
> > > > > 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 <
> dimas@apache.org>
> > > > > > 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 <
> > > > > kidjiofack@gmail.com>
> > > > > > > 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!
> > > > > > > >
> > > > > > >
> > > > >
> > > >
>

Re: On Using case insensitive storage type names.

[Robert Stupp <sn...@snazy.de>]

Yes, Jackson has a feature toggle for this behavior.

The breaking change would happen, as a newer client would break
against an older server using the same spec version.

Technically we have a lot of mapper instances floating around in
Polaris, in production and even more in test code.

The bigger issue is that the same (relevant) mapper instances are also
used for other APIs like the Iceberg one.

On Wed, Jan 7, 2026 at 11:43 AM Alexandre Dutra <ad...@apache.org> wrote:
>
> Hi all,
>
> First off, thank you, Innocent, for the recent PR [3349]!
>
> I've reviewed it and noted that it specifically special-cases the
> StorageConfigInfo enum for deserialization. Drawing on the discussion
> in [996], I believe we should adopt a more consistent approach: either
> all enums should be deserialized in a case-insensitive manner, or none
> should. Special-casing StorageConfigInfo feels unnecessarily
> complicated.
>
> I therefore recommend we investigate using Jackson's
> ACCEPT_CASE_INSENSITIVE_ENUMS Mapper feature [1] as a cleaner, more
> consistent solution.
>
> Regarding the REST API: I am questioning whether this change would be
> a breaking one. Existing clients should continue to function as
> expected. The only potential failure scenario I can imagine is a
> client intentionally sending an incorrect enum name and relying on it
> to fail, which seems unlikely. Therefore, a formal REST API
> specification change may not be necessary. What do others think?
>
> Thanks,
> Alex
>
> [1]: https://www.javadoc.io/doc/com.fasterxml.jackson.core/jackson-databind/latest/com/fasterxml/jackson/databind/MapperFeature.html#ACCEPT_CASE_INSENSITIVE_ENUMS
> [996]: https://github.com/apache/polaris/issues/996
> [3349]: https://github.com/apache/polaris/pull/3349
>
> On Tue, Jan 6, 2026 at 9:30 PM Dmitri Bourlatchkov
> <dm...@dremio.com> wrote:
> >
> > Hi Innocent,
> >
> > The most formal evolution doc we have is this:
> > https://polaris.apache.org/in-dev/unreleased/evolution/
> >
> > There is no working group. API changes are simply expected to be discussed
> > on `dev`.
> >
> > Cheers,
> > Dmitri.
> >
> > On Tue, Jan 6, 2026 at 3:25 PM Innocent Djiofack <ki...@gmail.com>
> > wrote:
> >
> > > 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 <sn...@snazy.de> 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 <ki...@gmail.com>
> > > > 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 <di...@apache.org>
> > > > > 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 <
> > > > kidjiofack@gmail.com>
> > > > > > 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!
> > > > > > >
> > > > > >
> > > >
> > >

Re: On Using case insensitive storage type names.

[Alexandre Dutra <ad...@apache.org>]

Hi all,

First off, thank you, Innocent, for the recent PR [3349]!

I've reviewed it and noted that it specifically special-cases the
StorageConfigInfo enum for deserialization. Drawing on the discussion
in [996], I believe we should adopt a more consistent approach: either
all enums should be deserialized in a case-insensitive manner, or none
should. Special-casing StorageConfigInfo feels unnecessarily
complicated.

I therefore recommend we investigate using Jackson's
ACCEPT_CASE_INSENSITIVE_ENUMS Mapper feature [1] as a cleaner, more
consistent solution.

Regarding the REST API: I am questioning whether this change would be
a breaking one. Existing clients should continue to function as
expected. The only potential failure scenario I can imagine is a
client intentionally sending an incorrect enum name and relying on it
to fail, which seems unlikely. Therefore, a formal REST API
specification change may not be necessary. What do others think?

Thanks,
Alex

[1]: https://www.javadoc.io/doc/com.fasterxml.jackson.core/jackson-databind/latest/com/fasterxml/jackson/databind/MapperFeature.html#ACCEPT_CASE_INSENSITIVE_ENUMS
[996]: https://github.com/apache/polaris/issues/996
[3349]: https://github.com/apache/polaris/pull/3349

On Tue, Jan 6, 2026 at 9:30 PM Dmitri Bourlatchkov
<dm...@dremio.com> wrote:
>
> Hi Innocent,
>
> The most formal evolution doc we have is this:
> https://polaris.apache.org/in-dev/unreleased/evolution/
>
> There is no working group. API changes are simply expected to be discussed
> on `dev`.
>
> Cheers,
> Dmitri.
>
> On Tue, Jan 6, 2026 at 3:25 PM Innocent Djiofack <ki...@gmail.com>
> wrote:
>
> > 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 <sn...@snazy.de> 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 <ki...@gmail.com>
> > > 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 <di...@apache.org>
> > > > 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 <
> > > kidjiofack@gmail.com>
> > > > > 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!
> > > > > >
> > > > >
> > >
> >

Re: On Using case insensitive storage type names.

[Dmitri Bourlatchkov <dm...@dremio.com>]

Hi Innocent,

The most formal evolution doc we have is this:
https://polaris.apache.org/in-dev/unreleased/evolution/

There is no working group. API changes are simply expected to be discussed
on `dev`.

Cheers,
Dmitri.

On Tue, Jan 6, 2026 at 3:25 PM Innocent Djiofack <ki...@gmail.com>
wrote:

> 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 <sn...@snazy.de> 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 <ki...@gmail.com>
> > 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 <di...@apache.org>
> > > 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 <
> > kidjiofack@gmail.com>
> > > > 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!
> > > > >
> > > >
> >
>

Re: On Using case insensitive storage type names.

[Innocent Djiofack <ki...@gmail.com>]

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 <sn...@snazy.de> 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 <ki...@gmail.com>
> 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 <di...@apache.org>
> > 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 <
> kidjiofack@gmail.com>
> > > 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!
> > > >
> > >
>

Re: On Using case insensitive storage type names.

[Robert Stupp <sn...@snazy.de>]

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 <ki...@gmail.com> 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 <di...@apache.org>
> 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 <ki...@gmail.com>
> > 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!
> > >
> >

Re: On Using case insensitive storage type names.

[Innocent Djiofack <ki...@gmail.com>]

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 <di...@apache.org>
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 <ki...@gmail.com>
> 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!
> >
>

Re: On Using case insensitive storage type names.

[Dmitri Bourlatchkov <di...@apache.org>]

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 <ki...@gmail.com>
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!
>