[CALCITE-5406] Support the SELECT DISTINCT ON statement for PostgreSQL dialect

[xuzifu666]

jira: https://issues.apache.org/jira/browse/CALCITE-5406

[cjj2010]

"DISTINCT ON" is a unique syntax of PGSQL. Would it be more appropriate to implement the parsing support for this function on the babel parser

[xuzifu666]

"DISTINCT ON" is a unique syntax of PGSQL. Would it be more appropriate to implement the parsing support for this function on the babel parser

1. Babel's only extensibility is:

Configuring additional keywords, join types, and binary operators in config.fmpp;

Adding custom parser methods (such as PostgreSQL's BEGIN/COMMIT) to includes/*.ftl.

Babel itself does not have a separate syntax file; all SELECT-related syntax must be defined in coreParser.jj.

2. Consistent with QUALIFY Implementation

QUALIFY is a syntax specific to Snowflake, which Calcite implements in the core:

The <QUALIFY> token is defined in core.Parser.jj.

The SqlSelect class adds a qualify field in the core.

The Validator/SqlToRelConverter logic is in the core; DISTINCT ON uses the exact same pattern.

3. Conformance Controls Semantics, Not Syntax

The current Parser unconditionally parses DISTINCT ON, but semantic validation is controlled by SqlConformance:

// Using `LENIENT conformance` in testing
`fixture().withConformance(SqlConformanceEnum.LENIENT)`

This is consistent with the handling of other extensions such as QUALIFY, LATERAL, and TABLESAMPLE: the Parser is as lenient as possible, and the Validator decides whether to allow based on the dialect.

so in my view：The current implementation conforms to Calcite's architectural conventions and does not require migration to Babel. For adjustments, finer-grained switches can be added to SqlConformance to control the availability of DISTINCT ON.

By the way: Besides PG, ClickHouse also supports DISTINCT ON.

[xiedeyantu]

I attempted to verify this across several databases (though my testing may not have been exhaustive) and indeed found that only PostgreSQL supports this syntax; furthermore, DISTINCT ON does not appear to be part of the standard SQL specification. I would suggest implementing this within Babel (specifically, by adding a configuration parameter to control it); we can also wait to see if anyone else has any better suggestions.

[xuzifu666]

I attempted to verify this across several databases (though my testing may not have been exhaustive) and indeed found that only PostgreSQL supports this syntax; furthermore, DISTINCT ON does not appear to be part of the standard SQL specification. I would suggest implementing this within Babel (specifically, by adding a configuration parameter to control it); we can also wait to see if anyone else has any better suggestions.

Good suggestion, I had add a config to control it in babel.

[xiedeyantu]

It seems like there’s a better place for this parameter.

[cjj2010]

Would it be better to add a test case similar to "SELECT DISTINCT ON (deptno)" here? I tried executing "SELECT DISTINCT ON (deptno)" and it didn't generate any error

[xuzifu666]

OK, I had added related test cases in SqlParserTest.java.

[cjj2010]

Perhaps it's a problem with my input method. I intended to add"SELECT DISTINCTON (deptno) empno" and "SELECT DISTINCT ON(deptno) empno". Scenarios like this, where text is written consecutively, should normally result in an error. However, the outcomes of the two situations I executed did not meet my expectations.
https://www.postgresql.org/docs/current/queries-select-lists.html#QUERIES-DISTINCT

[xuzifu666]

As far as I know, distinct on needs to be followed by an order by statement.

[cjj2010]

As far as I know, distinct on needs to be followed by an order by statement.

Perhaps I should elaborate and add test cases similar to "SELECT DISTINCTON (deptno) empno, ename FROM emp ORDER BY deptno, empno"

[sonarqubecloud]

Quality Gate passed

Issues
3 New issues
0 Accepted issues

Measures
0 Security Hotspots
91.2% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud