paul-rogers commented on code in PR #13777: URL: https://github.com/apache/druid/pull/13777#discussion_r1104791829
########## sql/src/main/java/org/apache/druid/sql/calcite/schema/InformationSchema.java: ########## @@ -73,44 +73,65 @@ public class InformationSchema extends AbstractSchema private static final String SCHEMATA_TABLE = "SCHEMATA"; private static final String TABLES_TABLE = "TABLES"; private static final String COLUMNS_TABLE = "COLUMNS"; - private static final RowSignature SCHEMATA_SIGNATURE = RowSignature Review Comment: This is, in fact, the core issue in this PR. If we use a Druid signature and round-trip to SQL, we lose SQL semantics. However, these are SQL, not Druid tables, so SQL semantics apply. If we were to execute system tables queries with a Druid engine then the most obvious choice is to integrate SQL semantics into the Druid engine. That is, numeric types can be null. There may be historical reasons why numbers can't be null in Druid, but there are also good historical reasons why numeric types can be null in SQL. The question is whether we want to alter SQL to follow Druid semantics or the other way around. I a consequence of using Druid semantics is that numbers sort in the wrong order, then I do suspect SQL is more right than Druid in this one case. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
