| PostgreSQL 8.3.3문서 | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Chapter 7. 쿼리 | Fast Forward | Next |
전절로 가리킨 것처럼, SELECT명령 중의 테이블식은, 테이블의 결합이나 뷰, 행의 추출, 그룹화등에 의해 중간의 가상 테이블을 만듭니다. 이 테이블은 최종적으로 선택 리스트에게 건네집니다. 선택 리스트는, 중간의 테이블의 어느 열 이 실제로 출력될지를 결정합니다.
테이블식이 생성하는 모든 열을 출력하는 *이 가장 간단한 선택 리스트입니다. 그렇지 않으면, 선택 리스트는, 컴마로 단락지어진(Section 4.2로 정의된) 평가식의 리스트입니다. 예를 들면, 이하와 같은 렬명의 리스트여도 상관하지 않습니다.
SELECT a, b, c FROM ...
a, b, c라고 하는 렬명은, FROM구로 참조되는 테이블의 실제의 렬명이나, 혹은 Section 7.2.1.2으로 설명한 것 같은 렬명에 대한 별명입니다. 그룹화되어 있지 않으면, 선택 리스트로 사용 가능한 이름 공간은 WHERE구와 같습니다. 그룹화 되고 있는 경우는, HAVING구로 같게됩니다.
만약, 두 가지 이상의 테이블이 같은 이름의 열이 있는 경우는, 다음과 같이, 테이블명을 반드시 지정하지 않으면 안됩니다.
SELECT tbl1.a, tbl2.a, tbl1.b FROM ...
복수의 테이블을 사용하는 경우, 특정의 테이블의 모든 열을 요구하는 방법도 편리할 수 있습니다.
SELECT tbl1.*, tbl2.a FROM ...
(Section 7.2.2도 참조해 주세요. )
임의의 평가식이 선택 리스트로 사용되는 경우, 돌려주어지는 테이블은, 개념적으로는 새롭게 가상적인 열을 추가한 것이 됩니다. 평가식은, 각각의 결과행으로, 그 열참조를 치환한 행의 값으로 해서 일단 평가됩니다. 그러나, 선택 리스트의 식은 FROM구로 지정된 테이블식에 기록되어 있는 일의 열을 참조하는 것일 필요는 없습니다. 예를 들면, 그것들은 정수 산술식에서도 상관하지 않습니다.
선택 리스트중의 항목은 후의 처리를 위해서 이름을 할당할 수가 있습니다. 이 경우의 "뒤의 처리"란, 옵션의 정렬 지정이나 클라이언트 어플리케이션입니다(예를 들면, 열헤더를 표시하기 위해서 사용합니다). 예를 나타냅니다.
SELECT a AS value, b + c AS sum FROM ...
만약, AS를 사용한 렬명의 지정이 없었던 경우, 시스템은, 기본값의 이름을 할당합니다. 단순한 열의 참조에서는, 참조된 렬명이 됩니다. 함수 호출에서는, 함수명이 됩니다. 복잡한 표현에 대해서는, 시스템이 범용의 이름을 생성합니다.
Note: 여기서의 출력열의 이름은, FROM구(Section 7.2.1.2를 참조)로 가리킨 것과는 다릅니다. 경로 처리로, 같은 열을 2번 개명하는 것이 가능합니다만, 선택 리스트 중에서 선택된 이름이 건네집니다.
선택 리스트가 처리된 후, 결과 테이블의 중복행을 삭제의 대상으로 할 수도 있습니다. 이것을 지정하기 위해서는, SELECT의 직후에 DISTINCT키워드를 기술합니다.
SELECT DISTINCT select_list ...
(DISTINCT대신에 ALL키워드를 지정하면, 모든 행이 기본값으로 보관 유지됩니다. )
적어도 1개의 열의 값이 다른 경우, 그 2행은 별개로 간주됩니다. NULL값은, 이 비교에 있어 동일하다고 보입니다.
또, 임의의 식을 사용해, 어느 행이 별도인지를 결정할 수도 있습니다.
SELECT DISTINCT ON (
expression
[,
expression
...])
select_list
...
expression 는, 모든 행으로 평가되는 임의의 평가식입니다. 모든 식이 동일해지는 행의 집합은, 중복하고 있는 것으로 보여 집합의 최초의 행만이 출력됩니다. DISTINCT필터 에 걸리는 행의 순서의 일의성을 보증할 수 있도록 쿼리가 열을 정렬하지 않는 한, 출력되는 집합의 "최초의 행"은 예상 불가능한 것을주의해 주세요 (DISTINCT ON처리는, ORDER BY에 의한 정렬 뒤에 행해집니다).
DISTINCT ON구는, 표준 SQL이 아닙니다. 게다가 결과가 부정이 될 가능성이 있기 때문에, 바람직하지 않은 스타일로 간주될 수도 있습니다. GROUP BY와 FROM중의 서브쿼리를 잘 사용하는 것으로, 이 구문을 사용하지 않고 끝납니다. 그러나, DISTINCT ON구는 많은 경우 매우 편리한 대안이 됩니다.