clintropolis commented on issue #17769: URL: https://github.com/apache/druid/issues/17769#issuecomment-2791004986
>It looks like if we change this to call parser.parseStmtList() instead of parser.parseStmt() we can parse lists of statements correctly, and then check for root being SqlNodeList in DruidPlanner ~here https://github.com/apache/druid/blob/master/sql/src/main/java/org/apache/druid/sql/calcite/planner/DruidPlanner.java#L145 and then do something based on whether or not there is a list of statements I opened #17894 which allows HTTP based SQL requests to do this. JDBC continues to work as it presently does since it doesn't really make sense to allow a JDBC statement to include more than 1 SQL statement and it already has a mechanism to define query context via the properties set on the connection when it is opened. If the syntax is acceptable and people don't think it is too weird to think of an SQL HTTP request as a single/complete session, I think it satisfies the first ask here - all of the other stuff sounds pretty nice to have too, especially the string requests (after the SET statement change) and the sys table with all the available context options. Validation is perhaps a bit trickier, but agree like you mentioned that we would need some sort of context registry to support a system table, so probably it wouldn't be too much effort to add some validation facilities to that if it exists. I do think we probably need to be considerate about this, particularly allowing unknown context parameters should probably be allowed (at least optionally), as I've seen this free form nature of the query context being used to attach additional custom tracking information to druid queries from applications so that it ends up available to metrics system. -- 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]
