hsyuan commented on pull request #1976:
URL: https://github.com/apache/calcite/pull/1976#issuecomment-628858500
The restriction only applies operator that implements `PhysicalNode`, which
is a newly introduced interface, no one has the chance to implement it until
1.23.0 is released.
hsyuan commented on pull request #1976:
URL: https://github.com/apache/calcite/pull/1976#issuecomment-628834771
The only possible case is the user's special rule creates a physical
operator that is a sub-class of Enumerable operator, at the same use Calcite's
built-in logical rule to
hsyuan commented on pull request #1976:
URL: https://github.com/apache/calcite/pull/1976#issuecomment-628802576
If it can match physical operators, that means it is already matches with
logical operators, it just generates redundant operators. What scenario will it
break?
hsyuan commented on pull request #1976:
URL: https://github.com/apache/calcite/pull/1976#issuecomment-628792593
> How do you guarantee only logical nodes are generated in transformation
rule?
It is allowed, but not encouraged. Just a contract, unless we add a check
inside
hsyuan commented on pull request #1976:
URL: https://github.com/apache/calcite/pull/1976#issuecomment-628739137
There won't be conflicts. It is the thorough fix.
This is an automated message from the Apache Git Service.
To
