Conversation
|
Workflow [PR], commit [06b9617] Summary: ❌
AI ReviewSummary ClickHouse Rules
Final Verdict
|
| const char * end_, | ||
| bool allow_settings_after_format_in_insert_ = false, | ||
| bool implicit_select_ = false, | ||
| bool allow_pipe_syntax_ = false) |
There was a problem hiding this comment.
ParserQuery now accepts allow_pipe_syntax, but this callsite still uses the 2-argument constructor, so allow_experimental_pipe_syntax is silently ignored in gRPC requests.
Impact: pipe queries (FROM ... |> ...) parse fine via normal server/client paths, but fail with syntax exception over gRPC even when the setting is enabled.
Please pass the setting explicitly here too, e.g.:
ParserQuery parser(
end,
settings[Setting::allow_settings_after_format_in_insert],
settings[Setting::implicit_select],
settings[Setting::allow_experimental_pipe_syntax]);There was a problem hiding this comment.
Need some more context in order to fix this. There are 20+ files where ParserQuery is used, I don't think that I need to introduce this feature flag everywhere(in other dialects parsers, fuzz queries etc.). Moreover, other 2 parser options are absent sometimes.
Added feature flag in GRPCServer.cpp, but maybe that not enough
LLVM Coverage Report
Changed lines: 69.38% (417/601) | lost baseline coverage: 8 line(s) · Uncovered code |
Changelog category:
Changelog entry:
Parser supports pipelined SQL syntax introduced by Google [1]. This syntax allows users to build queries top-to-bottom instead of current inside-out flow. Comparison of syntaxes can be found below.
allow_experimental_pipe_syntaxsetting enablesParserPipelinedQuerywhich for now supports filters, sortings, limitings, aggregations and joins. Parser produces the same AST as default parser so no changes on optimizer and executor is needed.Related issue: #69364
Documentation entry for user-facing changes
Pipe syntax adds a
|>operator that allows users to process data sequentially. Queries start with standaloneFROMclause and connect operators with pipes|>. Scope of subsequent clause is limited to output of previous operator.Settings:
allow_experimental_pipe_syntax- enables parsing of|>pipe operators (default = false)Supported operations:
|> WHERE <expr>- apply filters on rows|> ORDER BY <expr>- apply sorting|> LIMIT <n> [OFFSET <m>]- truncate output|> AGGREGATE <agg_expr>- full-table aggregation|> AGGREGATE <agg_expr> GROUP BY <grouping_expr>- aggregation with grouping|> [LEFT|...] JOIN <table_expr> [ON <condition>]- join operationExamples:
Query with standard SQL syntax
Pipelined equivalent
TPC-H 13 query translation:
[1] - SQL Has Problems. We Can Fix Them: Pipe Syntax in SQL