Skip to main content
이 설정은 system.settings에서 확인할 수 있으며, 소스 코드를 기반으로 자동 생성됩니다.

analyzer_compatibility_allow_compound_identifiers_in_unflatten_nested

Nested에 복합 식별자를 추가할 수 있도록 합니다. 이 설정을 사용하면 쿼리 결과가 변경되므로 compatibility 설정입니다. 비활성화되면 SELECT a.b.c FROM table ARRAY JOIN a는 동작하지 않으며, SELECT a FROM table의 Nested a 결과에 a.b.c 컬럼이 포함되지 않습니다.

analyzer_compatibility_allow_cte_redefinition

하나의 WITH 절에서 공통 테이블 표현식(Common Table Expression) 이름을 두 번 이상 정의할 수 있도록 허용합니다. 이러한 이름에 대한 참조는 그 시점에 해석 중이지 않은 가장 최근 정의에 바인딩됩니다. 즉, 재정의에서는 같은 이름의 이전 정의를 읽을 수 있으며, 쿼리 본문에서는 마지막 정의를 읽습니다. 이는 ClickHouse가 v24.3 이전에 사용하던 쿼리 분석 방식과 동일하며, 당시에는 나중 정의가 앞선 정의를 아무런 경고 없이 가렸습니다. 다만 한 가지 형태에서는 이전 분석 방식과 동작이 다릅니다. 같은 이름의 두 정의 사이에 선언된 CTE도 마지막 정의에 바인딩되지만, 이전 분석 방식에서는 해당 CTE가 선언 시점에 보이던 정의에 바인딩되었습니다. 기본적으로 재정의는 MULTIPLE_EXPRESSIONS_FOR_ALIAS 오류와 함께 거부됩니다. MATERIALIZED로 선언된 CTE와 WITH RECURSIVE 절의 CTE는 이 설정을 활성화하더라도 재정의할 수 없습니다. 가능한 값:
  • 0 - CTE 이름은 WITH 절에서 한 번만 정의할 수 있습니다.
  • 1 - CTE 이름의 나중 정의가 앞선 정의를 가립니다.

analyzer_compatibility_allow_non_aggregate_in_having

활성화하면 분석기는 NOT_AN_AGGREGATE를 발생시키는 대신 비집계 AND 조건을 HAVING에서 WHERE로 이동시키는 기존 동작을 모방합니다. SQL 표준을 따르는 거부 동작이 기본값이며, 이는 ClickHouse가 v24.3 이전에 사용했던 쿼리 분석에서 별다른 오류 없이 허용되던 쿼리를 위한 마이그레이션 보조 수단입니다. 집계, grouping 또는 비결정적 함수를 포함한 조건은 HAVING에 그대로 유지됩니다. 어떤 조건이든 윈도 함수 또는 상태 저장 함수(예: rowNumberInBlock)를 포함하면 전체 HAVING에 대해 재작성이 비활성화되며, 이는 이전 쿼리 분석의 동작과 일치합니다. 또한 GROUP BY에서 WITH CUBE, WITH ROLLUP, WITH TOTALS 또는 GROUPING SETS를 사용하는 경우 이 설정은 무시됩니다.

analyzer_compatibility_apply_final_to_all_joined_tables

26.6 이전 버전의 동작을 복원합니다. 이 동작에서는 JOIN의 가장 왼쪽 테이블에 지정된 FINAL 수정자가 다른 모든 조인 테이블에도 잘못 적용되었습니다(FINAL을 지원하는 엔진(예: ReplacingMergeTree)에 한함). 기본적으로 FINAL은 지정된 테이블에만 적용됩니다. 이전 동작에 의존하는 쿼리와의 호환성을 위해 활성화하십시오. 권장되는 해결 방법은 필요한 모든 테이블에 FINAL을 명시적으로 지정하는 것입니다. 가능한 값:
  • 0 - FINAL은 지정된 테이블에만 적용됩니다.
  • 1 - JOIN의 가장 왼쪽 테이블에 지정된 FINAL이 모든 조인 테이블에 적용됩니다.

analyzer_compatibility_join_using_top_level_identifier

projection에서 JOIN USING의 식별자를 해석하도록 강제합니다(예: SELECT a + 1 AS b FROM t1 JOIN t2 USING (b)에서는 t1.b = t2.b가 아니라 t1.a + 1 = t2.b를 기준으로 조인이 수행됩니다). WITH 절, SELECT 목록 내 하위 표현식, 기타 절 등 쿼리의 다른 위치에 정의된 별칭도 고려됩니다(예: WITH a + 1 AS b SELECT count() FROM t1 JOIN t2 USING (b) 및 SELECT uniqExact(a + 1 AS b) FROM t1 JOIN t2 USING (b)에서는 t1.a + 1 = t2.b를 기준으로 조인이 수행됩니다). 여러 개의 JOIN이 있는 쿼리에서는 가장 바깥쪽 JOIN만 별칭에서 USING 식별자를 해석하며, 내부 JOIN은 이전 분석기와 마찬가지로 왼쪽 테이블에서 식별자를 해석합니다. 일치하는 별칭이 SELECT 목록의 최상위 별칭이 아닌 경우, 해당 쿼리에서는 병렬 레플리카가 비활성화됩니다. 원격 서버로 전송되는 쿼리(Distributed 테이블, remote 테이블 함수)는 원격 서버에서 식별자를 전혀 해석할 수 없는 경우에만 예외와 함께 거부됩니다. 별칭이 왼쪽 테이블의 실제 컬럼을 가리는 경우 원격 서버는 대신 해당 컬럼을 기준으로 조인하므로, 결과가 로컬 실행과 다를 수 있습니다.

analyzer_compatibility_multiple_joins_qualify_column_names

활성화되어 있고 쿼리의 FROM 절에 2개 이상의 JOIN이 포함된 경우(쉼표로 구분된 테이블도 포함되지만 ARRAY JOIN은 제외됨), 분석기는 이전 분석기의 다중 조인 재작성 방식에 따라 결과 컬럼의 이름을 지정합니다.
  • *, <table>.* 또는 COLUMNS('<regexp>')를 확장해 생성된 컬럼은 <alias-or-table>.<column> 형식의 이름을 갖습니다(한정자는 테이블 표현식에 별칭이 있으면 해당 별칭, 없으면 데이터베이스명을 제외한 테이블명, 그 외에는 CTE 이름입니다. 별칭이 없는 조인된 하위 쿼리의 컬럼에는 한정자가 붙지 않습니다). 단일 테이블 표현식이 아니라 조인 자체에 속하는 두 종류의 컬럼은 한정자 없이 이름을 유지합니다. ARRAY JOIN으로 생성된 컬럼과 JOIN ... USING으로 머지된 키가 이에 해당합니다. 따라서 SELECT ll.arr 또는 SELECT ll.k와 같은 외부 참조는 이 두 경우에 해석되지 않습니다.
  • 식별자 목록 형식인 COLUMNS(col1, col2)는 매처 확장이 아닙니다. 각 컬럼은 식별자를 작성한 그대로의 이름을 유지하므로 COLUMNS(x)는 x를, COLUMNS(a.x)는 a.x를 생성합니다.
  • SELECT 목록에서 별칭이 없는 컬럼 참조는 작성한 그대로의 이름을 유지합니다(예: SELECT a.x는 x가 모호하지 않은 경우에도 a.x라는 이름의 컬럼을 생성합니다).
이렇게 하면 예를 들어 한정된 이름으로 이러한 컬럼을 참조하는 외부 쿼리가 작동합니다.

analyzer_compatibility_prefer_alias_over_subcolumn

b.id와 같은 다중 부분 식별자가 별칭이 b인 테이블의 컬럼 id를 가리킬 수도 있고 다른 컬럼의 Tuple subcolumn b.id를 가리킬 수도 있는 경우, 별칭 접두사로 해석하는 방식(b의 컬럼 id)을 우선합니다. 기본적으로 분석기는 subcolumn을 우선합니다. 이전 분석기의 해석 방식과 일치시키려면 이 설정을 활성화하십시오.