[CALCITE-6727] Column uniqueness constrain should only apply to inner…

[joeyutong]

In the existing test

// RelMetadataTest.java
@Test void testColumnUniquenessForJoinOnLimit1() {
  final String sql = ""
      + "select *\n"
      + "from emp A\n"
      + "join (\n"
      + "  select * from emp\n"
      + "  limit 1) B\n"
      + "on A.empno = B.empno";
  sql(sql)
      .assertThatAreColumnsUnique(bitSetOf(0), is(true))
      .assertThatAreColumnsUnique(bitSetOf(1), is(true))
      .assertThatAreColumnsUnique(bitSetOf(9), is(true))
      .assertThatAreColumnsUnique(bitSetOf(10), is(true))
      .assertThatAreColumnsUnique(bitSetOf(), is(true))
      .assertThatUniqueKeysAre(bitSetOf());
} 

the join result column A.ENAME is considered to be unique because A.EMPNO is the unique key. The test still passes when the query changes to left join, in which case A.ENAME is not guaranteed to be unique.

[mihaibudiu]

Why not add the test?

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud

[suibianwanwank]

LGTM

[mihaibudiu]

it is customary to add a JavaDoc comment to the test indicating the JIRA issue that is being addressed. This makes it easier for maintainers to understand the rationale for a test. You can find lots of examples in the code about how that is supposed to be structured, please follow the pattern.

[joeyutong]

Added the comment. Thanks for your reminder

[mihaibudiu]

is this correct even if maxRowCount is 0?

[joeyutong]

It seems to me that the constrain still works even when the build side is empty

[suibianwanwank]

+1

[joeyutong]

@mihaibudiu Any more thoughts on this? Please take another look when you have a moment