Fix applying settings for FORMAT on the client

[azat]

Changelog category (leave one):

• Backward Incompatible Change

Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):

Fix applying settings for FORMAT on the client

Previously the following query does not works correctly:

SELECT number FROM numbers(5) SETTINGS output_format_json_array_of_rows = 1 FORMAT JSONEachRow

While this one works OK:

SELECT number FROM numbers(5) FORMAT JSONEachRow SETTINGS output_format_json_array_of_rows = 1

The problem is in which AST those settings are stored, use the logic as executeQuery() has to apply them:

ClickHouse/src/Interpreters/executeQuery.cpp

Lines 467 to 497 in c83f701

	/// Interpret SETTINGS clauses as early as possible (before invoking the corresponding interpreter),
	/// to allow settings to take effect.
	if (const auto * select_query = ast->as<ASTSelectQuery>())
	{
	if (auto new_settings = select_query->settings())
	InterpreterSetQuery(new_settings, context).executeForCurrentContext();
	}
	else if (const auto * select_with_union_query = ast->as<ASTSelectWithUnionQuery>())
	{
	applySettingsFromSelectWithUnion(*select_with_union_query, context);
	}
	else if (const auto * query_with_output = dynamic_cast<const ASTQueryWithOutput *>(ast.get()))
	{
	if (query_with_output->settings_ast)
	InterpreterSetQuery(query_with_output->settings_ast, context).executeForCurrentContext();
	if (const auto * create_query = ast->as<ASTCreateQuery>())
	{
	if (create_query->select)
	{
	applySettingsFromSelectWithUnion(create_query->select->as<ASTSelectWithUnionQuery &>(), context);
	}
	}
	}
	else if (auto * insert_query = ast->as<ASTInsertQuery>())
	{
	context->setInsertFormat(insert_query->format);
	if (insert_query->settings_ast)
	InterpreterSetQuery(insert_query->settings_ast, context).executeForCurrentContext();
	insert_query->tail = istr;
	}

Note, the only problem should be with the settings for FORMAT, since client applies thoes settings (and formats) locally w/o server, while in case of i.e. HTTP it will be applied on the server and everything will works fine.

Refs: #45880 (cc @tavplubix @m1khal3v)
Follow-up for: #12480

[azat]

And now you can see the "reason" why it was written that way, after this patch the following query changes their behavior:

$ echo 'Custom true' | clickhouse-local -q "SELECT * FROM file('/dev/stdin', 'TSV', 'bool Bool') settings bool_true_representation='Custom true'"
Custom true

Before this PR clickhouse-client/clickhouse-local does not apply SETTINGS clause on the client side, but server does applies it, and so the server correctly parse Custom true as Bool(true), and so client outputs true

But, with this PR now client interpret bool_true_representation setting too, and that's why it outputs Custom true instead of true because this setting applies for both sides: deserialization and serialization.

Also here are few other variants without this patch, that may looks odd:

$ echo 'Custom true' | ch local -q "SELECT * FROM file('/dev/stdin', 'TSV', 'bool Bool') format TSV settings bool_true_representation='Custom true'"
Custom true

$ echo 'Custom true' | ch local -q "SELECT * FROM file('/dev/stdin', 'TSV', 'bool Bool')" --bool_true_representation='Custom true'
Custom true

[azat]

@tavplubix @Avogar or maybe @alexey-milovidov maybe you have some thoughts on this?

To me it looks odd that SETTINGS in one place, works differently.
Maybe there should be some setting like format_settings_context='none|both|serialization|deserilization' (or input/output)?

[tavplubix]

I like the new behavior more than the old one, thank you!

[tavplubix]

I think we can simply update the tests

[azat]

I think we can simply update the tests

I am a bit worried about serialization vs deserialization. But OK, let's try.

[tavplubix]

Integration tests (asan) [3/6] - #45437