23.2. 콜레이션 지원

23.2.1. 개념

개념적으로 콜레이션 가능한 데이터 타입의 모든 표현식은 콜레이션을 갖고 있다. (콜레이션 가능한 내장된 데이터 타입은 text 및 varchar, char이다. 사용자 정의된 베이스 타입은 콜레이션 가능으로 표시될 수 있으며, 콜레이션 가능한 데이터 타입의 도메인도 콜레이션이 가능하다.) 표현식이 칼럼 참조인 경우 표현식의 콜레이션은 칼럼이 정의한 콜레이션이다. 표현식이 상수인 경우 콜레이션은 상수 데이터 타입의 기본 콜레이션이다. 좀 더 복잡한 표현식의 콜레이션은 아래 설명대로 입력 콜레이션으로부터 결정된다.

표현식의 콜레이션은 데이터베이스에 대해 정의된 로케일(locale) 설정을 의미하는 "기본" 콜레이션이 될 수 있다. 표현식의 콜레이션을 결정되지 않은 상태로 하는 것도 가능하다. 이런 경우 콜레이션을 알아야 하는 정렬 명령 및 기타 명령은 실패한다.

데이터베이스 시스템이 정렬 또는 문자 분류를 수행해야 하는 경우 입력 표현식의 콜레이션이 사용된다. 이것은, 예를 들면 ORDER BY 절 및 함수 또는 < 같은 연산자 호출을 사용할 때 결정된다. ORDER BY 절에 적용되는 콜레이션은 단순히 정렬 키의 콜레이션이다. 함수 또는 연산자 호출에 적용되는 콜레이션은 아래 설명된 인자로부터 결정된다. 비교 연산자 외에, 콜레이션은 lower 및 upper, initcap 같이 대소문자 사이를 변환하는 함수와 그리고 패턴 일치 및 to_char와 관련 함수를 사용할 때 결정된다.

함수 또는 연산자 호출의 경우 인자 콜레이션 검사로 결정된 콜레이션이 작업 성능을 위해 런타임에 사용된다. 함수나 연산자 호출의 결과가 콜레이션 가능한 데이터 타입인 경우, 콜레이션에 대한 정보가 필요한 주변 표현식이 있을 때 콜레이션도 파싱 시 함수 또는 연산자 표현식의 정의된 콜레이션으로 사용된다.

표현식의 콜레이션 결정은 암시적 또는 명시적일 수 있다. 이 차이는 복수의 서로 다른 콜레이션이 표현식에 나타나는 경우 콜레이션이 결합되는 방식에 영향을 준다. COLLATE 절을 사용하면 명시적 콜레이션이 결정되고, 그 외 모든 콜레이션 파생은 암시적이다. 예를 들면, 함수 호출에서 복수의 콜레이션을 결합해야 하는 경우 다음과 같은 규칙이 사용된다.

1. 입력 표현식이 명시적 콜레이션을 결정하는 경우 입력 표현식에서 명시적으로 파생된 모든 콜레이션은 동일해야 한다. 그렇지 않으면 에러가 발생한다. 명시적으로 결정된 콜레이션은 콜레이션 결합의 결과물이다.

2. 그 외에는, 모든 입력 표현식은 동일한 암시적 콜레이션을 결정하거나 기본 콜레이션을 사용해야 한다. 기본값이 아닌 콜레이션은 콜레이션 결합의 결과물이다. 그 외에는 기본 콜레이션이다.

3. 입력 표현식 사이에 기본이 아닌 임시적 콜레이션의 충돌이 있을 경우 결합은 불확정적인 콜레이션을 쓰는 것으로 간주된다. 호출하려는 특수한 함수가 적용해야 할 콜레이션에 대한 지식을 필요로 하지 않는 경우에 한하여 이것은 에러 조건이 아니다. 그 외에는 런타임 시 에러가 발생된다.

예를 들어, 다음과 같은 테이블 정의를 생각해 보자.

CREATE TABLE test1 (
    a text COLLATE "de_DE",
    b text COLLATE "es_ES",
    ...
);

그러면,

SELECT a < 'foo' FROM test1;

이 구문에서 < 비교는, 표현식이 명시적으로 결정된 콜레이션을 기본 콜레이션과 결합하기 때문에 de_DE 규칙에 따라 수행된다. 그러나,

SELECT a < ('foo' COLLATE "fr_FR") FROM test1;

이 구문에서는 명시적 콜레이션이 암시적 콜레이션을 오버라이드하므로 fr_FR 규칙으로 비교가 수행된다. 게다가,

SELECT a < b FROM test1;

이 구문에서는 a 및 b 칼럼의 암시적 콜레이션이 충돌하므로 어떤 콜레이션을 적용할 것인지 파서로 결정할 수 없다. < 연산자는 어떤 콜레이션을 사용할 것인지 알 필요가 없으므로, 결과적으로 에러가 발생한다. 시적 콜레이션 지정자를 입력 표현식에 추가하면 이 에러가 해결된다. 따라서,

SELECT a < b COLLATE "de_DE" FROM test1;

또는 동일하게, 다음과 같이 할 수 있다.

SELECT a COLLATE "de_DE" < b FROM test1;

즉, 구조상 동일한,

SELECT a || b FROM test1;

이 구문은 || 연산자가 콜레이션에 대해 무심하므로 결과적으로 에러가 발생한다. 이 결과는 콜레이션과 무관하게 동일하다.

또한 함수 또는 연산자의 결합된 입력 표현식에 할당된 콜레이션은 함수 또는 연산자가 콜레이션 가능한 데이터 타입의 결과를 전달하는 경우, 함수 또는 연산자의 결과에 적용되는 것으로 간주된다. 따라서,

SELECT * FROM test1 ORDER BY a || 'foo';

이 구문은 de_DE 규칙에 따라 정렬된다. 그러나 이 쿼리는,

SELECT * FROM test1 ORDER BY a || b;

|| 연산자는 콜레이션에 대해 알고 있을 필요가 없지만 ORDER BY 절은 그렇게 하므로 결과적으로 에러가 발생한다. 이전과 같이, 명시적 콜레이션 지정자를 사용하면 충돌을 해결할 수 있다.

SELECT * FROM test1 ORDER BY a || b COLLATE "fr_FR";

23.2.2. 콜레이션 관리

콜레이션은 SQL 이름을 운영 체제 로케일(locale)에 매핑하는 SQL 스키마 개체이다. 특히, LC_COLLATE 및 LC_CTYPE 조합에 매핑한다. (이름이 암시하듯 콜레이션의 주요 목적은, 정렬 순서를 제어하는 LC_COLLATE를 설정하는 것이다. 그러나, 실제로는 LC_COLLATE와 다른 LC_CTYPE를 갖는 것은 거의 불필요하므로 표현식별로 LC_CTYPE 설정에 대한 다른 인프라를 생성하는 대신 한 가지 개념 하에서 이것을 수집하는 것이 더 편리하다.) 또한 콜레이션은 문자 집합 인코딩에 연결된다(23.3절 참조). 다른 인코딩으로 동일한 콜레이션 이름이 존재할 수도 있다.

모든 플랫폼에서 이름이 default 및 C, POSIX인 콜레이션을 사용할 수 있다. 추가 콜레이션은 운영 체제 지원에 따라 사용할 수 있다. default 콜레이션은 데이터베이스 생성 시에 지정된 LC_COLLATE 및 LC_CTYPE 값을 선택한다. C 및 POSIX 콜레이션 둘 다 ASCII 문자 "A" ~ "Z"만 글자로 처리되고 문자 코드 바이트 값으로 엄격하게 정렬이 되는 "전형적인 C" 동작을 지정한다.

운영 체제가 단일 프로그램(newlocale 및 관련 함수) 내에서 복수의 로케일(locale)을 사용하는 지원을 제공하는 경우 데이터베이스 클러스터가 초기화되면, initdb는 당시에 운영 체제에서 찾은 모든 로케일(locale)에 따라 콜레이션으로 시스템 카탈로그 pg_collation을 채운다. 예를 들면, 운영 체제는 de_DE.utf8이라는 이름의 로케일(locale)을 제공할 수도 있다. 그러면 initdb는 LC_COLLATE 및 LC_CTYPE가 둘 다 de_DE.utf8로 설정된 UTF8 인코딩에 대해 de_DE.utf8이라는 콜레이션을 생성한다. 또한 이것은 이름 일부만 추려낸 .utf8 태그를 사용하여 콜레이션을 생성한다. 따라서 작성이 간편하고 인코딩에 대한 이름 의존도가 낮은 de_DE라는 이름으로 콜레이션을 사용할 수도 있다. 그래도 콜레이션 이름의 초기 설정은 플랫폼에 따라 달라진다.

LC_COLLATE 및 LC_CTYPE에 대한 값이 서로 다른 콜레이션이 필요한 경우 CREATE COLLATION 명령을 사용하여 새로운 콜레이션을 생성할 수도 있다. 또한 해당 명령으로 기존 콜레이션에서 새 콜레이션을 생성할 수도 있으며, 이것은 애플리케이션에서 운영 체제로부터 독립된 콜레이션 이름을 사용할 때 유용하다.

특정한 데이터베이스 내에서 데이터베이스의 인코딩을 사용하는 콜레이션만 중요하다. pg_collation의 다른 항목은 무시된다. 따라서 de_DE 같이 일부만 추려낸 콜레이션 이름은 전역적으로는 고유하지 않더라도 지정된 데이터베이스 내에서는 고유한 것으로 간주될 수 있다. 데이터베이스 인코딩을 다른 것으로 변경하기로 결정한 경우 변경 사항이 적은 추려낸 콜레이션 이름을 사용하는 것이 권장한다. 그러나 default 및 C, POSIX 콜레이션은 데이터베이스 인코딩과 무관하게 사용할 수 있다.

PostgreSQL은 속성이 동일한 경우에도 별개의 콜레이션 개체는 호환되지 않는 것으로 간주한다. 따라서 예를 들면,

SELECT a COLLATE "C" < b COLLATE "POSIX" FROM test1;

이 구문은 C 및 POSIX 콜레이션의 동작이 동일하더라도 에러가 발생된다. 따라서 추려낸 콜레이션 이름과 추려내지 않은 콜레이션 이름의 혼용은 권장하지 않는다.