search

partiql / partiql-lang-kotlin

PartiQL libraries and tools in Kotlin.
https://partiql.org/
Apache License 2.0
538 stars 60 forks source link

Remove hard-coded function aliasing in ANTLR visitor #1459

Open alancai98 opened 4 months ago

alancai98 commented 4 months ago

Relevant Issue/Bug

None

Requested Solution/Feature

Currently in the ANTLR parser visitor, we convert function names matching CHARACTER_LENGTH and CHAR_LENGTH to the function name char_length:

https://github.com/partiql/partiql-lang-kotlin/blob/2879f3a0a1d3197cc00fda6f1613490f88d19353/partiql-parser/src/main/kotlin/org/partiql/parser/internal/PartiQLParserDefault.kt#L1871-L1872

This conversion should not be hard-coded within the ANTLR visitor. Realistically, there should be some alias field within the FnSignature that can specify any name alternatives:

https://github.com/partiql/partiql-lang-kotlin/blob/2879f3a0a1d3197cc00fda6f1613490f88d19353/partiql-spi/src/main/kotlin/org/partiql/spi/fn/FnSignature.kt#L24-L34

We could follow what Trino does w/ their ScalarFunction definition (i.e. define an alias string array):

https://github.com/trinodb/trino/blob/master/core/trino-spi/src/main/java/io/trino/spi/function/ScalarFunction.java#L32C14-L32C19

With this change, the function resolution would occur at a later stage (rather than during parsing) such as during planning using the specified connector metadata.

Describe Alternatives

  1. Leave as it is? <- Can be problematic for future UDFs that may have aliases.
  2. Some other way to pass along aliases (e.g. previous way to pass along a map of function names to signatures). <- I think adding an alias field to the existing APIs is less confusing for the end user.

Additional Context

Add any other context about the feature request here.

DoD (Definition of Done)

alancai98 commented 4 months ago

Also applicable to aggregation functions (e.g. SOME and ANY): https://ronsavage.github.io/SQL/sql-99.bnf.html#some