Thank Alex for raising this! I agree with the general direction here. One additional character we may want to consider is `+`. While technically valid in many contexts, it behaves inconsistently across HTTP stacks and URL handling layers. Some servers, proxies, and frameworks may decode `+` into a space, especially when form URL encoding semantics leak into path or query handling. For example, an identifier like `my+table` may later be interpreted as `my table` depending on the component processing the request.
I also wonder whether we should avoid backticks " ` " for similar interoperability reasons. They are commonly used as identifier quoting characters in SQL dialects and can create escaping or rendering awkwardness across SQL generation, CLI tooling, and markdown/documentation flows. Given Polaris identifiers flow through REST paths, SDKs, proxies, engines/SQL layers, and CLI tooling, keeping the allowed identifier set conservative may help reduce long tail interoperability issues. Yufei On Wed, May 20, 2026 at 1:57 PM Dmitri Bourlatchkov <[email protected]> wrote: > Hi Alex, > > The proposed restrictions make sense to me. > > I approved the PR in GH. > > Cheers, > Dmitri. > > On Wed, May 20, 2026 at 4:50 PM Alexandre Dutra <[email protected]> wrote: > > > Hi all, > > > > We recently added some safeguards around entity names [1]. > > > > As I mentioned before [2], I think we could go a bit further and > > forbid characters that most cloud providers either forbid, or strongly > > advise against. > > > > These are: > > > > - Control characters > > - Backslash `\` > > - Path segments equal to `.` or `..` > > - Commonly discouraged symbols: * ? " < > | # > > > > I opened a PR recently to implement this suggestion [3]. > > > > What do you all think? > > > > Thanks, > > Alex > > > > [1]: https://github.com/apache/polaris/pull/4282 > > [2]: https://lists.apache.org/thread/g54czqdfw2r7k7cxrtfd84wtd52kxps4 > > [3]: https://github.com/apache/polaris/pull/4479 > > >
