Support subcolumns in default and materialized expressions#74403
Support subcolumns in default and materialized expressions#74403Avogar merged 11 commits intoClickHouse:masterfrom
Conversation
|
This is an automated comment for commit d16da86 with description of existing statuses. It's updated for the latest CI running ❌ Click here to open a full report in a separate page
Successful checks
|
|
|
||
| /// Create an alias for getSubcolumn function so it has the name of the subcolumn. | ||
| const auto & alias_node = extract_subcolumns_dag.addAlias(function_node, input->result_name); | ||
| extract_subcolumns_dag.addOrReplaceInOutputs(alias_node); |
There was a problem hiding this comment.
I think it is safer to support the map with added output names. In this case, we can skip adding unused getSubcolumn, and replace this line to extract_subcolumns_dag.getOutputs().push_back(alias_node)
There was a problem hiding this comment.
I think it is safer to support the map with added output names.
But how it's possible to add the same name as output twice here? Each added output corresponds to a different subcolumn. Using extract_subcolumns_dag.getOutputs().push_back(alias_node) should be enough.
TBH I used addOrReplaceInOutputs not because I was afraid of duplicates but because I didn't thinking about getOutputs().push_back :)
a17dc26 to
4916e3c
Compare
4916e3c to
b97d8c0
Compare
ece0003
|
This fix depends on the setting allow_experimental_analyzer=1; |
Do ypu have an example when it doesn't work without analyzer? BTW, analyzer is not experimental anymore and enabled by default since 24.3. There is an alias |
|
I see, it is indeed a problem with old analyzer. But I don't think we want to fix such things with old analyzer, it's better to switch to the new one. |
|
It is not clear why this fix depends on this setting. |
|
The problem is in |
|
Okay, I'll wait for the full implementation. |
|
What do you mean by full implementation? |
|
The allow_experimental_analyzer setting is disabled in the cloud service. For this reason, it doesn't work without setting in queries or profiles. Without this, accessibility will only be possible after removing the dependency on this setting. |
It is disabled for old services for compatibility. You can test if enabling it doesn't break your queries and enable it by default for your profile or ask the support to enable it by default for the whole service. |
|
I have already asked the service a question. Their position is unequivocal: experimental setting is disabled. I know about the profile and will use it in some cases. Thanks! |
That is strange, analyzer is not expiremental anymore for long time already. Maybe they were confused by the setting name |
|
if the analyzer is turned on and the experimental one is turned off, the error is reproduced. |
|
There is no experimental analyzer. |
Changelog category (leave one):
Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):
Support subcolumns in default and materialized expressions
Documentation entry for user-facing changes
CI Settings (Only check the boxes if you know what you are doing)
All builds in Builds_1 and Builds_2 stages are always mandatory
and will run independently of the checks below: