# Aurora DSQL의 SQL 기능 호환성
이어지는 섹션에서는 PostgreSQL 데이터 유형 및 SQL 명령에 대한 Aurora DSQL 지원에 대해 알아봅니다.
**Topics**
+ [Aurora DSQL에서 지원되는 데이터 유형](working-with-postgresql-compatibility-supported-data-types.md)
+ [Aurora DSQL에 지원되는 SQL](working-with-postgresql-compatibility-supported-sql-features.md)
+ [Aurora DSQL에서 지원되는 SQL 명령 하위 집합](working-with-postgresql-compatibility-supported-sql-subsets.md)
+ [PostgreSQL에서 Aurora DSQL로 마이그레이션](working-with-postgresql-compatibility-migration-guide.md)
# Aurora DSQL에서 지원되는 데이터 유형
Aurora DSQL은 일반적인 PostgreSQL 유형의 하위 집합을 지원합니다.
**Topics**
+ [숫자 데이터 유형](#numeric-data-types)
+ [문자 데이터 유형](#character-data-types)
+ [날짜 및 시간 데이터 유형](#date-time-data-types)
+ [기타 데이터 유형](#miscellaneous-data-types)
+ [쿼리 런타임 데이터 유형](#working-with-postgresql-compatibility-query-runtime)
## 숫자 데이터 유형
Aurora DSQL은 다음 PostgreSQL 숫자 데이터 유형을 지원합니다.
| 이름 | 에일리어스 | 범위 및 정밀도 | 스토리지 크기 | 인덱스 지원 |
| --- | --- | --- | --- | --- |
| smallint | int2 | 2 bytes | 2 bytes | 예 |
| `integer` | `int`, `int4` | 4 bytes | 4비트 | 예 |
| `bigint` | `int8` | -9,223,372,036,854,775,808\$1\$19,223,372,036,854,775,807 | 8 bytes | 예 |
| `real` | `float4` | 소수 자릿수 6까지의 정밀도 | 4비트 | 예 |
| `double precision` | `float8` | 소수 자릿수 15까지의 정밀도 | 8 bytes | 예 |
| `numeric` [ `(`*p*, *s*`)` ] | `decimal` [ `(`*p*, *s*`)` ] `dec`[ `(`*p*,*s*`)`] | 정밀도를 선택할 수 있는 정확한 숫자. 최대 정밀도는 38이며 최대 범위는 37이고1 기본값은 `numeric (18,6)`입니다. | 정밀도 숫자당 8바이트 \$1 2바이트. 최대 크기는 27바이트입니다. | 예 |
1 - `CREATE TABLE` 또는 `ALTER TABLE ADD COLUMN`을 실행할 때 크기를 명시적으로 지정하지 않으면 Aurora DSQL이 기본값을 적용합니다. `INSERT` 또는 `UPDATE` 문을 실행할 때 Aurora DSQL은 제한을 적용합니다.
## 문자 데이터 유형
Aurora DSQL은 다음 PostgreSQL 문자 데이터 유형을 지원합니다.
| 이름 | 에일리어스 | 설명 | Aurora DSQL 제한 | 스토리지 크기 | 인덱스 지원 |
| --- | --- | --- | --- | --- | --- |
| `character` [ `(`*n*`)` ] | `char` [ `(`*n*`)` ] | 고정 길이 문자열 | 4,096B1 | 최대 4,100바이트까지 가변 | 예 |
| `character varying` [ `(`*n*`)` ] | `varchar` [ `(`*n*`)` ] | 가변 길이 문자열 | 65,535B1 | 최대 65,539바이트까지 가변 | 예 |
| `bpchar` [ `(`*n*`)` ] | | 고정 길이인 경우 `char`의 별칭입니다. 가변 길이인 경우 이는 후행 공백이 의미상 유의하지 않은 `varchar`의 별칭입니다. | 4,096B1 | 최대 4,100바이트까지 가변 | 예 |
| `text` | | 가변 길이 문자열 | 1MiB1 | 최대 1MiB까지 가변 | 예 |
1 - `CREATE TABLE` 또는 `ALTER TABLE ADD COLUMN`을 실행할 때 크기를 명시적으로 지정하지 않으면 Aurora DSQL이 기본값을 적용합니다. `INSERT` 또는 `UPDATE` 문을 실행할 때 Aurora DSQL은 제한을 적용합니다.
## 날짜 및 시간 데이터 유형
Aurora DSQL은 다음 PostgreSQL 날짜 및 시간 데이터 유형을 지원합니다.
| 이름 | 에일리어스 | 설명 | Range | 해결 방법 | 스토리지 크기 | 인덱스 지원 |
| --- | --- | --- | --- | --- | --- | --- |
| `date` | | 날짜(년, 월, 일) | 4713 BC\$15874897 AD | 1일 | 4비트 | 예 |
| `time` [ `(`*p*`)` ] [ `without time zone` ] | `timestamp` | 시간대가 없는 시간 | 0\$11 | 1마이크로초 | 8 bytes | 예 |
| `time` [ `(`*p*`)` ] `with time zone` | `timetz` | 시간대를 포함한 시간 | 00:00:00\$11,559\$124:00:00 –1,559 | 1마이크로초 | 12바이트 | 아니요 |
| `timestamp` [ `(`*p*`)` ] [ `without time zone` ] | | 시간대가 없는 날짜 및 시간 | 4713 BC\$1294276 AD | 1마이크로초 | 8 bytes | 예 |
| `timestamp` [ `(`*p*`)` ] `with time zone` | `timestamptz` | 시간대를 포함한 날짜 및 시간 | 4713 BC\$1294276 AD | 1마이크로초 | 8 bytes | 예 |
| `interval` [ `fields` ] [ `(`*p*`)` ] | | 시간 범위 | -178,000,000년\$1178,000,000년 | 1마이크로초 | 16바이트 | 아니요 |
## 기타 데이터 유형
Aurora DSQL은 다음과 같은 기타 PostgreSQL 데이터 유형을 지원합니다.
| 이름 | 에일리어스 | 설명 | Aurora DSQL 제한 | 스토리지 크기 | 인덱스 지원 |
| --- | --- | --- | --- | --- | --- |
| `boolean` | `bool` | 논리적 부울(true/false) | | 1바이트 | 예 |
| `bytea` | | 바이너리 데이터('바이트 배열') | 1MiB1 | 최대 1MiB까지 가변 | 아니요 |
| `UUID` | | 범용 고유 식별자 | | 16바이트 | 예 |
1 - `CREATE TABLE` 또는 `ALTER TABLE ADD COLUMN`을 실행할 때 크기를 명시적으로 지정하지 않으면 Aurora DSQL이 기본값을 적용합니다. `INSERT` 또는 `UPDATE` 문을 실행할 때 Aurora DSQL은 제한을 적용합니다.
## 쿼리 런타임 데이터 유형
쿼리 런타임 데이터 유형은 쿼리 실행 시점에 사용되는 내부 데이터 유형입니다. 이러한 유형은 스키마에서 정의하는 `varchar` 및 `integer`와 같은 PostgreSQL 호환 유형과 다릅니다. 대신 이러한 유형은 Aurora DSQL이 쿼리를 처리할 때 사용하는 런타임 표현입니다.
다음 데이터 유형은 쿼리 런타임 중에만 지원됩니다.
**배열 유형**
Aurora DSQL은 지원되는 데이터 유형의 배열을 지원합니다. 예를 들어 정수 배열이 있을 수 있습니다. `string_to_array` 함수는 다음 예시처럼 쉼표 구분 기호(`,`)를 사용하여 문자열을 PostgreSQL 스타일 배열로 분할합니다. 쿼리 실행 중에 표현식, 함수 출력 또는 임시 계산에 배열을 사용할 수 있습니다.
```
SELECT string_to_array('1,2', ',');
```
이 함수는 다음과 유사한 응답을 반환합니다.
```
string_to_array
-----------------
{1,2}
(1 row)
```
****inet 유형****
이 데이터 유형은 IPv4, IPv6 호스트 주소 및 해당 서브넷을 나타냅니다. 이 유형은 로그를 구문 분석하거나, IP 서브넷에서 필터링하거나, 쿼리 내에서 네트워크 계산을 수행할 때 유용합니다. 자세한 내용은 PostgreSQL 설명서의 [inet](https://www.PostgreSQL.org/docs/16/datatype-net-types.html#DATATYPE-INET)을 참조하세요.
**JSON 런타임 함수**
Aurora DSQL은 쿼리 처리를 위한 런타임 데이터 유형으로 JSON 및 JSONB를 지원합니다. JSON 데이터를 `text` 열로 저장할 수 있으며 쿼리 실행 시 JSON으로 캐스팅하여 PostgreSQL JSON 함수와 연산자를 사용할 수 있습니다.
Aurora DSQL은 [9.1.6 섹션 JSON 함수 및 연산자](https://www.postgresql.org/docs/current/functions-json.html)에 명시된 대부분의 PostgreSQL JSON 함수를 동일한 동작으로 지원합니다.
JSON 또는 JSONB 유형을 반환하는 함수는 올바른 표시를 위해 `text`로 추가 형변환이 필요할 수 있습니다.
```
SELECT json_build_array(1, 2, 'foo', 4, 5)::text;
```
이 함수는 다음과 유사한 응답을 반환합니다.
```
json_build_array
---------------------
[1, 2, "foo", 4, 5]
(1 row)
```
# Aurora DSQL에 지원되는 SQL
Aurora DSQL은 다양한 핵심 PostgreSQL SQL 기능을 지원합니다. 이어지는 섹션에서는 일반적인 PostgreSQL 표현식 지원에 대해 알아볼 수 있습니다. 단, 이 목록이 전부는 아닙니다.
## `SELECT` 명령
Aurora DSQL은 `SELECT` 명령의 다음 절을 지원합니다.
| 기본 절 | 지원 절 |
| --- | --- |
| `FROM` | |
| `GROUP BY` | `ALL`, `DISTINCT` |
| `ORDER BY` | `ASC`, `DESC`, `NULLS` |
| `LIMIT` | |
| `DISTINCT` | |
| `HAVING` | |
| `USING` | |
| `WITH`(공통 테이블 표현식) | |
| `INNER JOIN` | `ON` |
| `OUTER JOIN` | `LEFT`, `RIGHT`, `FULL`, `ON` |
| `CROSS JOIN` | `ON` |
| `UNION` | `ALL` |
| `INTERSECT` | `ALL` |
| `EXCEPT` | `ALL` |
| `OVER` | `RANK ()`, `PARTITION BY` |
| `FOR UPDATE` | |
## 데이터 정의 언어(DDL)
Aurora DSQL은 다음과 같은 PostgreSQL DDL 명령을 지원합니다.
| Command | 기본 절 | 지원 절 |
| --- | --- | --- |
| `CREATE` | `TABLE` | `CREATE TABLE` 명령의 지원되는 구문에 대한 자세한 내용은 [`CREATE TABLE`](create-table-syntax-support.md) 섹션을 참조하세요. |
| `ALTER` | `TABLE` | `ALTER TABLE` 명령의 지원되는 구문에 대한 자세한 내용은 [`ALTER TABLE`](alter-table-syntax-support.md) 섹션을 참조하세요. |
| `DROP` | `TABLE` | |
| `CREATE` | `[UNIQUE] INDEX ASYNC` | 이 명령과 `ON`, `NULLS FIRST`, `NULLS LAST` 파라미터를 함께 사용할 수 있습니다. `CREATE INDEX ASYNC` 명령의 지원되는 구문에 대한 자세한 내용은 [Aurora DSQL의 비동기 인덱스](working-with-create-index-async.md) 섹션을 참조하세요. |
| `DROP` | `INDEX` | |
| `CREATE` | `VIEW` | `CREATE VIEW` 명령의 지원되는 구문에 대한 자세한 내용은 [`CREATE VIEW`](create-view.md) 섹션을 참조하세요. |
| ALTER | VIEW | `ALTER VIEW` 명령의 지원되는 구문에 대한 자세한 내용은 [`ALTER VIEW`](alter-view-syntax-support.md) 섹션을 참조하세요. |
| DROP | VIEW | DROP VIEW 명령의 지원되는 구문에 대한 자세한 내용은 [`DROP VIEW`](drop-view-overview.md) 섹션을 참조하세요. |
| `CREATE` | `SEQUENCE` | `CREATE SEQUENCE` 명령의 지원되는 구문에 대한 자세한 내용은 [`CREATE SEQUENCE`](create-sequence-syntax-support.md) 섹션을 참조하세요. |
| `ALTER` | `SEQUENCE` | `ALTER SEQUENCE` 명령의 지원되는 구문에 대한 자세한 내용은 [`ALTER SEQUENCE`](alter-sequence-syntax-support.md) 섹션을 참조하세요. |
| `DROP` | `SEQUENCE` | `DROP SEQUENCE` 명령의 지원되는 구문에 대한 자세한 내용은 [`DROP SEQUENCE`](drop-sequence-syntax-support.md) 섹션을 참조하세요. |
| `CREATE` | `ROLE`, `WITH` | |
| `CREATE` | `FUNCTION` | `LANGUAGE SQL` |
| `CREATE` | `DOMAIN` | |
## 데이터 조작 언어(DML)
Aurora DSQL은 다음과 같은 PostgreSQL DML 명령을 지원합니다.
| Command | 기본 절 | 지원 절 |
| --- | --- | --- |
| `INSERT` | `INTO` | `VALUES`SELECT |
| `UPDATE` | `SET` | `WHERE (SELECT)` `FROM, WITH` |
| DELETE | FROM | USING, WHERE |
## 데이터 제어 언어(DCL)
Aurora DSQL은 다음과 같은 PostgreSQL DCL 명령을 지원합니다.
| Command | 지원 절 |
| --- | --- |
| `GRANT` | `ON`, `TO` |
| `REVOKE` | `ON`, `FROM`, `CASCADE`, `RESTRICT` |
## 트랜잭션 제어 언어(TCL)
Aurora DSQL은 다음과 같은 PostgreSQL TCL 명령을 지원합니다.
| Command | 지원 절 | 별칭 |
| --- | --- | --- |
| `COMMIT` | [`WORK` \$1 `TRANSACTION`] [`AND NO CHAIN`] | `END` |
| `BEGIN` | [`WORK` \$1 `TRANSACTION`] [`ISOLATION LEVEL REPEATABLE READ`] [`READ WRITE` \$1 `READ ONLY`] | |
| `START TRANSACTION` | [`ISOLATION LEVEL REPEATABLE READ`] [`READ WRITE` \$1 `READ ONLY`] | |
| `ROLLBACK` | [`WORK` \$1 `TRANSACTION`] [`AND NO CHAIN`] | `ABORT` |
## 유틸리티 명령
Aurora DSQL은 다음과 같은 PostgreSQL 유틸리티 명령을 지원합니다.
+ `EXPLAIN`
+ `ANALYZE`(관계 이름만 해당)
# Aurora DSQL에서 지원되는 SQL 명령 하위 집합
이 섹션에서는 광범위한 파라미터 세트 및 하위 명령이 있는 명령에 중점을 두고 지원되는 SQL 명령에 대한 자세한 정보를 제공합니다. 예를 들어 PostgreSQL의 CREATE TABLE은 Aurora DSQL에서 지원하는 하위 집합인 여러 절과 파라미터를 제공합니다. 이 섹션에서는 Aurora DSQL이 지원하는 익숙한 PostgreSQL 구문 요소를 사용하여 지원되는 일반적인 SQL 명령의 하위 집합을 설명합니다.
**Topics**
+ [`CREATE TABLE`](create-table-syntax-support.md)
+ [`ALTER TABLE`](alter-table-syntax-support.md)
+ [`CREATE SEQUENCE`](create-sequence-syntax-support.md)
+ [`ALTER SEQUENCE`](alter-sequence-syntax-support.md)
+ [`DROP SEQUENCE`](drop-sequence-syntax-support.md)
+ [`CREATE VIEW`](create-view.md)
+ [`ALTER VIEW`](alter-view-syntax-support.md)
+ [`DROP VIEW`](drop-view-overview.md)
# `CREATE TABLE`
`CREATE TABLE`은 새 테이블을 정의합니다.
```
CREATE TABLE [ IF NOT EXISTS ] table_name ( [
{ column_name data_type [ column_constraint [ ... ] ]
| table_constraint
| LIKE source_table [ like_option ... ] }
[, ... ]
] )
where column_constraint is:
[ CONSTRAINT constraint_name ]
{ NOT NULL |
NULL |
CHECK ( expression )|
DEFAULT default_expr |
GENERATED ALWAYS AS ( generation_expr ) STORED |
GENERATED { ALWAYS | BY DEFAULT } AS IDENTITY ( sequence_options ) |
UNIQUE [ NULLS [ NOT ] DISTINCT ] index_parameters |
PRIMARY KEY index_parameters |
and table_constraint is:
[ CONSTRAINT constraint_name ]
{ CHECK ( expression ) |
UNIQUE [ NULLS [ NOT ] DISTINCT ] ( column_name [, ... ] ) index_parameters |
PRIMARY KEY ( column_name [, ... ] ) index_parameters |
and like_option is:
{ INCLUDING | EXCLUDING } { COMMENTS | CONSTRAINTS | DEFAULTS | GENERATED | IDENTITY | INDEXES | STATISTICS | ALL }
index_parameters in UNIQUE, and PRIMARY KEY constraints are:
[ INCLUDE ( column_name [, ... ] ) ]
```
## ID 열
**참고**
자격 증명 열을 사용할 때는 캐시 값을 신중하게 고려해야 합니다. 자세한 내용은 [`CREATE SEQUENCE`](create-sequence-syntax-support.md) 페이지의 중요 안내를 참조하세요.
워크로드 패턴을 기반으로 자격 증명 열을 가장 잘 사용하는 방법에 대한 지침은 [시퀀스 및 자격 증명 열 작업](sequences-identity-columns-working-with.md) 섹션을 참조하세요.
`GENERATED { ALWAYS | BY DEFAULT } AS IDENTITY ( sequence_options )` 절은 열을 *자격 증명 열*로 만듭니다. 암시적 시퀀스가 연결되고 새로 삽입된 행에서 열은 할당된 시퀀스의 값을 자동으로 갖습니다. 이러한 열은 암시적으로 `NOT NULL`입니다.
`ALWAYS` 및 `BY DEFAULT` 절은 `INSERT` 및 `UPDATE` 명령에서 사용자 지정 값을 명시적으로 처리하는 방법을 결정합니다.
`INSERT` 명령에서 `ALWAYS`가 선택된 경우 `INSERT` 문이 `OVERRIDING SYSTEM VALUE`를 지정하는 경우에만 사용자 지정 값이 허용됩니다. `BY DEFAULT`를 선택하면 사용자 지정 값이 우선합니다.
`UPDATE` 명령에서 `ALWAYS`가 선택된 경우 열을 이외의 값으로 업데이트하면 `DEFAULT`가 거부됩니다. `BY DEFAULT`를 선택하면 열을 정상적으로 업데이트할 수 있습니다. (`UPDATE`명령에는 `OVERRIDING` 절이 없습니다.)
*sequence\$1options* 절을 사용하여 시퀀스의 파라미터를 재정의할 수 있습니다. 사용 가능한 옵션에는 [`CREATE SEQUENCE`](create-sequence-syntax-support.md)에 대해 표시된 옵션과 `SEQUENCE NAME name`이 포함됩니다. `SEQUENCE NAME`이 없으면 시스템에서 시퀀스에 사용되지 않는 이름을 선택합니다.
# `ALTER TABLE`
`ALTER TABLE`은 테이블의 정의를 변경합니다.
```
ALTER TABLE [ IF EXISTS ] [ ONLY ] name [ * ]
action [, ... ]
ALTER TABLE [ IF EXISTS ] [ ONLY ] name [ * ]
RENAME [ COLUMN ] column_name TO new_column_name
ALTER TABLE [ IF EXISTS ] [ ONLY ] name [ * ]
RENAME CONSTRAINT constraint_name TO new_constraint_name
ALTER TABLE [ IF EXISTS ] name
RENAME TO new_name
ALTER TABLE [ IF EXISTS ] name
SET SCHEMA new_schema
where action is one of:
ADD [ COLUMN ] [ IF NOT EXISTS ] column_name data_type
ALTER [ COLUMN ] column_name { SET GENERATED { ALWAYS | BY DEFAULT } | SET sequence_option | RESTART [ [ WITH ] restart ] } [...]
ALTER [ COLUMN ] column_name DROP IDENTITY [ IF EXISTS ]
OWNER TO { new_owner | CURRENT_ROLE | CURRENT_USER | SESSION_USER }
```
## 자격 증명 열 작업
**`SET GENERATED { ALWAYS | BY DEFAULT }` / `SET sequence_option` / `RESTART`**
이러한 양식은 열이 자격 증명 열인지 아니면 기존 자격 증명 열의 생성 속성을 변경하는지 여부를 변경합니다. 세부 정보는 [`CREATE TABLE`](create-table-syntax-support.md) 섹션을 참조하세요. `SET DEFAULT`와 마찬가지로 이러한 형식은 후속 `INSERT` 및 `UPDATE` 명령의 동작에만 영향을 미치며 테이블에 이미 있는 행은 변경되지 않습니다.
*sequence\$1option*은 `INCREMENT BY`와 같이 [`ALTER SEQUENCE`](alter-sequence-syntax-support.md)에서 지원하는 옵션입니다. 이러한 형식은 기존 자격 증명 열의 기반이 되는 시퀀스를 변경합니다.
**`DROP IDENTITY [ IF EXISTS ]`**
이 양식은 열에서 자격 증명 속성을 제거합니다. `DROP IDENTITY IF EXISTS`가 지정되어 있고 열이 자격 증명 열이 아닌 경우 오류가 발생하지 않습니다. 이 경우 대신 알림이 발행됩니다.
# `CREATE SEQUENCE`
`CREATE SEQUENCE` - 새 시퀀스 생성기를 정의합니다.
**중요**
PostgreSQL에서 `CACHE` 지정은 선택 사항이며 기본값은 1입니다. Amazon Aurora DSQL과 같은 분산 시스템에서 시퀀스 작업은 조정을 포함하며, 캐시 크기가 1이면 동시성이 높을 때 조정 오버헤드가 증가할 수 있습니다. 캐시 값이 크면 로컬에 미리 할당된 범위에서 시퀀스 번호를 제공할 수 있으므로, 처리량이 향상되고 사용하지 않는 예약 값이 손실되어 간격과 순서 지정 효과를 더 명확하게 확인할 수 있습니다. 애플리케이션마다 할당 순서와 처리량에 대한 민감도가 다르기 때문에 Amazon Aurora DSQL은 `CACHE`를 명시적으로 지정하도록 요구하며, 현재 `CACHE = 1` 또는 `CACHE >= 65536`을 지원하므로 엄격한 순차 생성에 더 가까운 할당 동작과 높은 동시성 워크로드에 최적화된 할당을 명확히 구분하도록 해 줍니다.
`CACHE >= 65536`인 경우 시퀀스 값은 고유하게 유지되지만 세션 간에 엄격하게 증가하는 순서로 생성되지 않을 수 있으며, 특히 캐시된 값이 완전히 사용되지 않는 경우 간격이 발생할 수 있습니다. 이러한 특성은 동시 사용 시 캐시된 시퀀스에 대한 PostgreSQL 의미 체계와 일치하며, 두 시스템 모두 고유한 값을 보장하지만 세션 간에 엄격하게 순차적인 순서 지정을 보장하지는 않습니다.
단일 클라이언트 세션 내에서 시퀀스 값은 특히 명시적 트랜잭션 외부에서 항상 엄격하게 증가하는 것처럼 보이지 않을 수 있습니다. 이 동작은 연결 풀링을 사용하는 PostgreSQL 배포와 유사합니다. 단일 세션 PostgreSQL 환경에 더 가까운 할당 동작은 `CACHE = 1`을 사용하거나 명시적 트랜잭션 내에서 시퀀스 값을 가져와 달성할 수 있습니다.
`CACHE = 1`을 사용하면 시퀀스 할당이 PostgreSQL의 캐시되지 않은 시퀀스 동작을 따릅니다.
워크로드 패턴을 기반으로 시퀀스를 가장 잘 사용하는 방법에 대한 지침은 [시퀀스 및 자격 증명 열 작업](sequences-identity-columns-working-with.md) 섹션을 참조하세요.
## 지원되는 구문
```
CREATE SEQUENCE [ IF NOT EXISTS ] name CACHE cache
[ AS data_type ]
[ INCREMENT [ BY ] increment ]
[ MINVALUE minvalue | NO MINVALUE ] [ MAXVALUE maxvalue | NO MAXVALUE ]
[ [ NO ] CYCLE ]
[ START [ WITH ] start ]
[ OWNED BY { table_name.column_name | NONE } ]
where data_type is BIGINT
and cache = 1 or cache >= 65536
```
## 설명
`CREATE SEQUENCE`는 새 시퀀스 번호 생성기를 생성합니다. 여기에는 이름이 *name*인 새 특수 단일 행 테이블을 생성하고 초기화하는 작업이 포함됩니다. 명령을 실행하는 사용자가 생성기를 소유합니다.
스키마 이름이 제공되면 지정된 스키마에 시퀀스가 생성됩니다. 그러지 않으면 현재 스키마에서 생성됩니다. 시퀀스 이름은 동일한 스키마 내의 다른 관계(테이블, 시퀀스, 인덱스, 뷰, 구체화된 뷰 또는 외부 테이블)의 이름과 달라야 합니다.
시퀀스가 생성되면 함수 `nextval`, `currval` 및 `setval`을 사용하여 시퀀스에서 작업합니다. 이러한 함수는 [시퀀스 조작 함수](sequence-functions-syntax-support.md)에 설명되어 있습니다.
시퀀스를 직접 업데이트할 수는 없지만 다음과 같은 쿼리를 사용할 수 있습니다.
```
SELECT * FROM name;
```
시퀀스의 일부 파라미터와 현재 상태를 검사합니다. 특히 시퀀스의 `last_value` 필드에는 세션에서 할당한 마지막 값이 표시됩니다. (물론 다른 세션이 적극적으로 `nextval` 직접 호출을 수행하는 경우 이 값은 출력되는 시점에 더 이상 사용되지 않을 수 있습니다.) `pg_sequences` 뷰에서 *increment* 및 *maxvalue*와 같은 다른 파라미터를 관찰할 수 있습니다.
## 파라미터
**`IF NOT EXISTS`**
동일한 이름의 관계가 이미 있는 경우 오류를 발생시키지 않습니다. 이 경우 알림이 발행됩니다. 기존 관계가 생성되었을 시퀀스와 비슷하다는 보장은 없으며 시퀀스가 아닐 수도 있습니다.
*** 이름***
생성할 시퀀스의 이름(선택적으로 스키마 한정자 포함)입니다.
***data\$1type***
선택적 절 `AS data_type`은 시퀀스의 데이터 형식을 지정합니다. 유효한 값은 `bigint`이며, `bigint`가 기본값입니다. 데이터 형식에 따라 시퀀스의 기본 최솟값과 최댓값이 결정됩니다.
***increment***
선택적 절 `INCREMENT BY increment`은 새 값을 생성하기 위해 현재 시퀀스 값에 추가할 값을 지정합니다. 양수 값은 오름차순 시퀀스를 만들고, 음수 값은 내림차순 시퀀스를 만듭니다. 기본값은 1입니다.
***minvalue* / `NO MINVALUE`**
선택적 절 `MINVALUE minvalue`는 시퀀스가 생성할 수 있는 최솟값을 결정합니다. 이 절이 제공되지 않거나 `NO MINVALUE`가 지정된 경우 기본값이 사용됩니다. 오름차순 시퀀스의 기본값은 1입니다. 내림차순 시퀀스의 기본값은 데이터 형식의 최솟값입니다.
***maxvalue* / `NO MAXVALUE`**
선택적 절 `MAXVALUE maxvalue`는 시퀀스의 최댓값을 결정합니다. 이 절이 제공되지 않거나 `NO MAXVALUE`가 지정된 경우 기본값이 사용됩니다. 오름차순 시퀀스의 기본값은 데이터 형식의 최댓값입니다. 내림차순 시퀀스의 기본값은 -1입니다.
**`CYCLE` / `NO CYCLE`**
`CYCLE` 옵션을 사용하면 각각 오름차순 또는 내림차순 시퀀스에 의해 *maxvalue* 또는 *minvalue*에 도달했을 때 시퀀스를 래핑할 수 있습니다. 한도에 도달하면 생성되는 다음 숫자는 각각 *minvalue* 또는 *maxvalue*가 됩니다.
`NO CYCLE`이 지정된 경우 시퀀스가 최댓값에 도달한 후 `nextval`을 직접적으로 호출하면 오류가 반환됩니다. `CYCLE` 및 `NO CYCLE`을 둘 다 지정하지 않으면 `NO CYCLE`이 기본값입니다.
***시작***
선택적 절 `START WITH start`를 사용하면 어디서나 시퀀스를 시작할 수 있습니다. 기본 시작 값은 오름차순 시퀀스의 경우 *minvalue*이고 내림차순 시퀀스의 경우 *maxvalue*입니다.
***cache***
절 `CACHE cache`는 더 빠른 액세스를 위해 사전 할당되고 메모리에 저장될 시퀀스 번호의 수를 지정합니다. Aurora DSQL에서 `CACHE`에 허용되는 값은 1 또는 65,536 이상의 모든 숫자입니다. 최솟값은 1입니다(한 번에 하나의 값만 생성할 수 있으므로 캐시가 없음).
**`OWNED BY table_name.column_name` / `OWNED BY NONE`**
`OWNED BY` 옵션을 사용하면 시퀀스가 특정 테이블 열과 연결되므로 해당 열(또는 전체 테이블)이 삭제되면 시퀀스도 자동으로 삭제됩니다. 지정된 테이블은 소유자가 동일해야 하며 시퀀스와 동일한 스키마에 있어야 합니다. 기본값인 `OWNED BY NONE`은 이러한 연결이 없음을 지정합니다.
## 참고
[`DROP SEQUENCE`](drop-sequence-syntax-support.md)를 사용하여 시퀀스를 제거합니다.
시퀀스는 `bigint` 산술을 기반으로 하므로 범위는 8바이트 정수(-9,223,372,036,854,775,808\$19,223,372,036,854,775,807)의 범위를 초과할 수 없습니다.
`nextval` 및 `setval` 직접 호출은 롤백되지 않으므로 시퀀스 번호의 ‘간격 없는’ 할당이 필요한 경우 시퀀스 객체를 사용할 수 없습니다.
각 세션은 시퀀스 객체에 대한 한 번의 액세스 중에 연속 시퀀스 값을 할당 및 캐싱하고 그에 따라 시퀀스 객체의 `last_value`를 늘립니다. 그런 다음 해당 세션 내에서 다음번에 `nextval`을 *cache*-1번 사용하면 시퀀스 객체를 터치하지 않고 미리 할당된 값을 반환하기만 합니다. 따라서 세션 내에서 할당되었지만 사용되지 않은 모든 숫자는 해당 세션이 종료될 때 손실되어 시퀀스에서 '구멍'이 됩니다.
또한 여러 세션이 고유한 시퀀스 값을 할당하도록 보장되지만 모든 세션이 고려되면 값이 시퀀스를 벗어나 생성될 수 있습니다. 예를 들어 *cache* 설정이 10인 경우 세션 A가 값 1..10을 예약하고 `nextval`=1을 반환한 다음, 세션 B는 세션 A가 `nextval`=2를 생성하기 전에 값 11..20을 예약하고 `nextval`=11을 반환할 수 있습니다. 따라서 *cache* 설정이 1이면 `nextval` 값이 순차적으로 생성된다고 가정하는 것이 안전합니다. *cache* 설정이 1보다 크면 `nextval` 값이 순차적으로만 생성되지 않고 모두 고유하다고 가정해야 합니다. 또한 `last_value`는 `nextval`에서 아직 반환했는지 여부에 관계없이 모든 세션에서 예약한 최신 값을 반영합니다.
또 다른 고려 사항은 이러한 시퀀스에서 실행된 `setval`은 캐싱된 미리 할당된 값을 모두 사용할 때까지 다른 세션에서 인식되지 않는다는 것입니다.
## 예제
101부터 시작하여 `serial`이라는 오름차순 시퀀스를 생성합니다.
```
CREATE SEQUENCE serial CACHE 65536 START 101;
```
이 시퀀스에서 다음 번호를 선택합니다.
```
SELECT nextval('serial');
nextval
---------
101
```
이 시퀀스에서 다음 번호를 선택합니다.
```
SELECT nextval('serial');
nextval
---------
102
```
`INSERT` 명령에서 이 시퀀스를 사용합니다.
```
INSERT INTO distributors VALUES (nextval('serial'), 'nothing');
```
`setval`을 사용하여 시퀀스를 특정 값으로 재설정합니다.
```
SELECT setval('serial', 200);
SELECT nextval('serial');
nextval
---------
201
```
## 호환성
`CREATE SEQUENCE`는 SQL 표준을 준수합니다. 단, 다음은 예외입니다.
+ 다음 값 가져오기는 표준 `NEXT VALUE FOR` 표현식 대신 `nextval()` 함수를 사용하여 수행됩니다.
+ `OWNED BY` 절은 PostgreSQL 확장입니다.
# `ALTER SEQUENCE`
`ALTER SEQUENCE` - 시퀀스 생성기의 정의를 변경합니다.
**중요**
시퀀스를 사용할 때는 캐시 값을 신중하게 고려해야 합니다. 자세한 내용은 [`CREATE SEQUENCE`](create-sequence-syntax-support.md) 페이지의 중요 안내를 참조하세요.
워크로드 패턴을 기반으로 시퀀스를 가장 잘 사용하는 방법에 대한 지침은 [시퀀스 및 자격 증명 열 작업](sequences-identity-columns-working-with.md) 섹션을 참조하세요.
## 지원되는 구문
```
ALTER SEQUENCE [ IF EXISTS ] name
[ INCREMENT [ BY ] increment ]
[ MINVALUE minvalue | NO MINVALUE ] [ MAXVALUE maxvalue | NO MAXVALUE ]
[ [ NO ] CYCLE ]
[ START [ WITH ] start ]
[ RESTART [ [ WITH ] restart ] ]
[ CACHE cache ]
[ OWNED BY { table_name.column_name | NONE } ]
ALTER SEQUENCE [ IF EXISTS ] name OWNER TO { new_owner | CURRENT_ROLE | CURRENT_USER | SESSION_USER }
ALTER SEQUENCE [ IF EXISTS ] name RENAME TO new_name
ALTER SEQUENCE [ IF EXISTS ] name SET SCHEMA new_schema
where cache is 1 or cache >= 65536
```
## 설명
`ALTER SEQUENCE`는 기존 시퀀스 생성기의 파라미터를 변경합니다. `ALTER SEQUENCE` 명령에 구체적으로 설정되지 않은 파라미터는 이전 설정을 유지합니다.
`ALTER SEQUENCE`를 사용하려면 시퀀스를 소유해야 합니다. 시퀀스의 스키마를 변경하려면 새 스키마에 대한 `CREATE` 권한도 있어야 합니다. 소유자를 변경하려면 새 소유 역할에 `SET ROLE`을 수행할 수 있어야 하며 해당 역할에 시퀀스의 스키마에 대한 `CREATE` 권한이 있어야 합니다. (이러한 제한은 소유자를 변경해도 시퀀스를 삭제하고 다시 생성하여 수행할 수 없는 작업은 수행하지 않도록 강제합니다. 그러나 수퍼유저는 어떤 시퀀스의 소유권도 변경할 수 있습니다.)
## 파라미터
***이름***
변경할 시퀀스의 이름(선택적으로 스키마 한정자 포함)입니다.
**`IF EXISTS`**
시퀀스가 없는 경우 오류가 발생하지 않습니다. 이 경우 알림이 발행됩니다.
***increment***
`INCREMENT BY increment` 절은 선택 사항입니다. 양수 값은 오름차순 시퀀스를 만들고, 음수 값은 내림차순 시퀀스를 만듭니다. 지정하지 않으면 이전 증분 값이 유지됩니다.
***minvalue* / `NO MINVALUE`**
선택적 절 `MINVALUE minvalue`는 시퀀스가 생성할 수 있는 최솟값을 결정합니다. `NO MINVALUE`를 지정하면 오름차순 및 내림차순 시퀀스에 대해 1 및 해당 데이터 형식의 최솟값이 기본값으로 각각 사용됩니다. 두 옵션을 모두 지정하지 않으면 현재 최솟값이 유지됩니다.
***maxvalue* / `NO MAXVALUE`**
선택적 절 `MAXVALUE maxvalue`는 시퀀스의 최댓값을 결정합니다. `NO MAXVALUE`를 지정하면 오름차순 및 내림차순 시퀀스에 대해 해당 데이터 형식의 최댓값과 -1이 기본값으로 각각 사용됩니다. 두 옵션을 모두 지정하지 않으면 현재 최댓값이 유지됩니다.
**`CYCLE`**
선택적 `CYCLE` 키워드를 사용하여 각각 오름차순 또는 내림차순 시퀀스에 의해 *maxvalue* 또는 *minvalue*에 도달했을 때 시퀀스를 래핑할 수 있습니다. 한도에 도달하면 생성되는 다음 숫자는 각각 *minvalue* 또는 *maxvalue*가 됩니다.
**`NO CYCLE`**
선택적 `NO CYCLE` 키워드가 지정된 경우 시퀀스가 최댓값에 도달한 후 `nextval`을 직접적으로 호출하면 오류가 반환됩니다. `CYCLE` 및 `NO CYCLE`를 모두 지정하지 않으면 이전 주기 동작이 유지됩니다.
***시작***
선택적 절 `START WITH start`는 시퀀스의 기록된 시작 값을 변경합니다. 이는 현재 시퀀스 값에 영향을 주지 않으며, 향후 `ALTER SEQUENCE RESTART` 명령에서 사용할 값을 설정하기만 합니다.
***재시작***
선택적 절 `RESTART [ WITH restart ]`는 시퀀스의 현재 값을 변경합니다. 이는 `is_called` = `false`로 `setval` 함수를 직접적으로 호출하는 것과 유사합니다. 지정된 값은 `nextval`의 다음 직접 호출에 의해 반환됩니다. *restart* 값 없이 `RESTART`를 쓰는 것은 `CREATE SEQUENCE`에서 기록했거나 `ALTER SEQUENCE START WITH`에서 마지막으로 설정한 시작 값을 제공하는 것과 같습니다.
`setval` 직접 호출과 달리 시퀀스에 대한 `RESTART` 작업은 트랜잭션이며 동시 트랜잭션이 동일한 시퀀스에서 번호를 얻는 것을 차단합니다. 원하는 작업 모드가 아닌 경우 `setval`을 사용해야 합니다.
***cache***
절 `CACHE cache`를 사용하면 더 빠른 액세스를 위해 시퀀스 번호를 미리 할당하고 메모리에 저장할 수 있습니다. 값은 1이거나 65,536 이상이어야 합니다. 지정하지 않으면 이전 캐시 값이 유지됩니다. 캐시 동작에 대한 자세한 내용은 [`CREATE SEQUENCE`](create-sequence-syntax-support.md) 아래의 지침을 참조하세요.
**`OWNED BY table_name.column_name` / `OWNED BY NONE`**
`OWNED BY` 옵션을 사용하면 시퀀스가 특정 테이블 열과 연결되므로 해당 열(또는 전체 테이블)이 삭제되면 시퀀스도 자동으로 삭제됩니다. 지정된 경우 이 연결은 시퀀스에 대해 이전에 지정된 연결을 대체합니다. 지정된 테이블은 소유자가 동일해야 하며 시퀀스와 동일한 스키마에 있어야 합니다. `OWNED BY NONE`를 지정하면 기존 연결이 제거되어 시퀀스가 ‘독립적으로 존재하는 상태’가 됩니다.
***new\$1owner***
새 시퀀스 소유자의 사용자 이름입니다.
***new\$1name***
시퀀스의 새 이름입니다.
***new\$1schema***
시퀀스의 새 스키마입니다.
## 참고
`ALTER SEQUENCE`는 사전 할당된(캐싱된) 시퀀스 값이 있는 현재 백엔드를 제외하면 백엔드의 `nextval` 결과에 즉시 영향을 미치지 않습니다. 변경된 시퀀스 생성 파라미터를 확인하기 전에 캐시된 모든 값을 사용합니다. 현재 백엔드는 즉시 영향을 받습니다.
`ALTER SEQUENCE`는 시퀀스의 `currval` 상태에 영향을 주지 않습니다.
`ALTER SEQUENCE`는 다른 트랜잭션을 OCC로 만들 수 있습니다.
기록상 이유로 시퀀스에도 `ALTER TABLE`을 사용할 수 있지만, 시퀀스에서 허용되는 `ALTER TABLE`의 유일한 변형은 위에 표시된 형식과 동일합니다.
## 예제
105에서 `serial`이라는 시퀀스를 다시 시작합니다.
```
ALTER SEQUENCE serial RESTART WITH 105;
```
## 호환성
`ALTER SEQUENCE`는 PostgreSQL 확장인 `AS`, `START WITH`, `OWNED BY`, `OWNER TO`, `RENAME TO`, `SET SCHEMA` 절을 제외하고 SQL 표준을 준수합니다.
# `DROP SEQUENCE`
`DROP SEQUENCE` - 시퀀스를 제거합니다.
## 지원되는 구문
```
DROP SEQUENCE [ IF EXISTS ] name [, ...] [ CASCADE | RESTRICT ]
```
## 설명
`DROP SEQUENCE`는 시퀀스 번호 생성기를 제거합니다. 시퀀스는 소유자 또는 수퍼유저만 삭제할 수 있습니다.
## 파라미터
**`IF EXISTS`**
시퀀스가 없는 경우 오류가 발생하지 않습니다. 이 경우 알림이 발행됩니다.
*** 이름***
시퀀스의 이름(선택적으로 스키마 한정자 포함)입니다.
**`CASCADE`**
확장에 종속된 객체와 해당 객체에 종속된 모든 객체가 자동으로 삭제됩니다.
**`RESTRICT`**
종속된 객체가 있는 경우 시퀀스를 삭제하는 것을 거부합니다. 이 값이 기본값입니다.
## 예제
`seq` 시퀀스 제거:
```
DROP SEQUENCE seq;
```
## 호환성
`DROP SEQUENCE`는 SQL 표준을 준수합니다. 그러나 표준에서는 명령당 하나의 시퀀스만 삭제할 수 있으며 PostgreSQL 확장 기능인 `IF EXISTS` 옵션이 제외되어 있다는 점이 다릅니다.
# `CREATE VIEW`
`CREATE VIEW`는 새로운 영구 뷰를 정의합니다. Aurora DSQL은 임시 뷰를 지원하지 않으며 영구 뷰만 지원됩니다.
## 지원되는 구문
```
CREATE [ OR REPLACE ] [ RECURSIVE ] VIEW name [ ( column_name [, ...] ) ]
[ WITH ( view_option_name [= view_option_value] [, ... ] ) ]
AS query
[ WITH [ CASCADED | LOCAL ] CHECK OPTION ]
```
## 설명
`CREATE VIEW`는 쿼리 뷰를 정의합니다. 이 뷰는 물리적으로 구체화되지 않습니다. 대신 쿼리에서 뷰가 참조될 때마다 쿼리가 실행됩니다.
`CREATE or REPLACE VIEW`는 비슷하지만 동일한 이름의 뷰가 이미 있는 경우 대체됩니다. 새 쿼리는 기존 뷰 쿼리에서 생성된 것과 동일한 열(즉, 동일한 순서로 동일한 데이터 유형을 가진 동일한 열 이름)을 생성해야 하지만 목록 끝에 추가 열을 추가할 수 있습니다. 출력 열을 생성하는 계산은 다를 수 있습니다.
스키마 이름이 지정되어 있는 경우(예: `CREATE VIEW myschema.myview ...`), 뷰는 지정된 스키마에서 생성됩니다. 그렇지 않으면, 뷰가 현재 스키마에서 생성됩니다.
뷰의 이름은 동일한 스키마에 있는 다른 관계(테이블, 인덱스, 뷰)의 이름과 달라야 합니다.
## 파라미터
`CREATE VIEW`는 다양한 파라미터를 지원하여 자동으로 업데이트 가능한 뷰의 동작을 제어합니다.
**`RECURSIVE`**
재귀 뷰를 생성합니다. `CREATE RECURSIVE VIEW [ schema . ] view_name (column_names) AS SELECT ...;` 구문은 `CREATE VIEW [ schema . ] view_name AS WITH RECURSIVE view_name (column_names) AS (SELECT ...) SELECT column_names FROM view_name;`과 동일합니다.
재귀 뷰에 대해 뷰 열 이름 목록을 지정해야 합니다.
**`name`**
생성할 뷰의 이름으로, 선택적으로 스키마가 지정될 수 있습니다. 재귀 뷰에 열 이름 목록을 지정해야 합니다.
**`column_name`**
뷰에서 열에 사용할 이름의 선택적 목록입니다. 지정되지 않은 경우에는 열 이름이 쿼리에서 추론됩니다.
**`WITH ( view_option_name [= view_option_value] [, ... ] )`**
이 절은 뷰에 대한 선택적 파라미터를 지정합니다. 다음 파라미터가 지원됩니다.
+ `check_option (enum)` -이 파라미터는 `local` 또는 `cascaded`일 수 있으며 `WITH [ CASCADED | LOCAL ] CHECK OPTION` 지정과 동일합니다.
+ `security_barrier (boolean)` - 뷰가 행 수준 보안을 제공해야 하는 경우 이 옵션을 사용해야 합니다. Aurora DSQL은 현재 행 수준 보안을 지원하지 않지만 이 옵션은 뷰의 `WHERE` 조건(및 `LEAKPROOF`로 표시된 연산자를 사용하는 모든 조건)을 먼저 평가하도록 강제합니다.
+ `security_invoker (boolean)` -이 옵션을 사용하면 뷰 소유자가 아닌 뷰 사용자의 권한을 기준으로 기본 관계를 확인할 수 있습니다. 자세한 내용은 아래 참고 사항을 참조하세요.
위의 모든 옵션은 기존 뷰에서 `ALTER VIEW`를 사용하여 변경할 수 있습니다.
**`query`**
뷰의 열과 행을 제공하는 `SELECT` 또는 `VALUES` 명령입니다.
**`WITH [ CASCADED | LOCAL ] CHECK OPTION`**
이 옵션은 자동으로 업데이트 가능한 뷰의 동작을 제어합니다. 이 옵션을 지정하면 새 행이 뷰 정의 조건을 충족하는지 확인하기 위해 뷰의 `INSERT` 및 `UPDATE` 명령이 확인됩니다(즉, 새 행이 뷰를 통해 표시되는지 확인함). 충족하지 않으면 업데이트가 거부됩니다. `CHECK OPTION`이 지정되지 않은 경우 뷰의 `INSERT` 및 `UPDATE` 명령은 뷰를 통해 표시되지 않는 행을 생성할 수 있습니다.
`LOCAL` - 새 행은 뷰 자체에 직접 정의된 조건을 기준으로만 확인됩니다. 기본 뷰에 정의된 조건은 아무것도 확인되지 않습니다(`CHECK OPTION`을 지정하지 않는 한).
`CASCADED` - 뷰 및 모든 기본 뷰의 조건을 기준으로 새 행이 확인됩니다. `CHECK OPTION`이 지정되고 `LOCAL`과 `CASCADED`는 지정되지 않으면 `CASCADED`가 수임됩니다.
`CHECK OPTION`은 `RECURSIVE` 뷰와 함께 사용할 수 없습니다. `CHECK OPTION`은 자동으로 업데이트 가능한 뷰에서만 지원됩니다.
## 참고
`DROP VIEW` 문을 사용하여 뷰를 삭제합니다.
뷰 열의 이름과 데이터 유형을 신중하게 고려해야 합니다. 예를 들어 CREATE VIEW vista AS SELECT 'Hello World';는 열 이름의 기본값이 `?column?;`이므로 권장되지 않습니다. 또한 열 데이터 유형은 기본적으로 `text`로 설정되며, 이는 원하는 것과 다를 수 있습니다.
더 나은 방법은 `CREATE VIEW vista AS SELECT text 'Hello World' AS hello;`와 같이 열 이름과 데이터 유형을 명시적으로 지정하는 것입니다.
기본적으로 뷰에서 참조되는 기본 관계에 대한 액세스는 뷰 소유자의 권한에 따라 결정됩니다. 경우에 따라 기본 테이블에 대한 안전하고 제한된 액세스를 제공하는 데 사용할 수 있습니다. 그러나 모든 뷰가 변조로부터 안전한 것은 아닙니다.
+ 뷰에 `security_invoker` 속성이 true로 설정된 경우 기본 관계에 대한 액세스는 뷰 소유자가 아닌 쿼리를 실행하는 사용자의 권한에 따라 결정됩니다. 따라서 보안 호출자 뷰의 사용자는 뷰 및 기본 관계에 대한 관련 권한이 있어야 합니다.
+ 기본 관계가 보안 호출자 뷰인 경우 원래 쿼리에서 직접 액세스한 것처럼 처리됩니다. 따라서 보안 호출자 뷰는 `security_invoker` 속성이 없는 뷰에서 액세스하더라도 항상 현재 사용자의 권한을 사용하여 기본 관계를 확인합니다.
+ 뷰에서 직접 호출된 함수는 뷰를 사용하여 쿼리에서 직접 호출된 것과 동일하게 처리됩니다. 따라서 뷰 사용자에게 뷰에서 사용하는 모든 함수를 직접 호출할 수 있는 권한이 있어야 합니다. 뷰의 함수는 함수가 `SECURITY INVOKER`와 `SECURITY DEFINER` 중 무엇으로 정의되었는지에 따라 쿼리를 실행하는 사용자 또는 함수 소유자의 권한으로 실행됩니다.
+ 뷰를 생성하거나 교체하는 사용자는 스키마에서 참조된 객체를 조회하기 위해 뷰 쿼리에서 참조된 스키마에 대한 `USAGE` 권한이 있어야 합니다.
+ 기존 뷰에서 `CREATE OR REPLACE VIEW`를 사용하는 경우 뷰의 정의 `SELECT` 규칙과 `WITH ( ... )` 파라미터 및 해당 `CHECK OPTION`만 변경됩니다. 소유권, 권한 및 SELECT가 아닌 규칙을 포함한 다른 뷰 속성은 변경되지 않습니다. 뷰를 대체하려면 뷰를 소유해야 합니다(소유 역할의 멤버가 되는 것 포함).
## 업데이트 가능한 뷰
단순 뷰는 자동으로 업데이트할 수 있습니다. 시스템에서는 일반 테이블과 동일한 방식으로 뷰에서 `INSERT`, `UPDATE` 및 `DELETE` 문을 사용하도록 허용합니다. 뷰는 다음 조건을 모두 충족하는 경우 자동으로 업데이트됩니다.
+ 뷰는 `FROM` 목록에 정확히 하나의 항목이 있어야 하며,이 항목은 테이블 또는 다른 업데이트 가능한 뷰여야 합니다.
+ 뷰 정의에서 최상위 수준에 `WITH`, `DISTINCT`, `GROUP BY`, `HAVING`, `LIMIT` 또는 `OFFSET` 절이 포함되어서는 안 됩니다.
+ 뷰 정의에서 최상위 수준에 세트 작업(`UNION`, `INTERSECT` 또는 `EXCEPT`)이 포함되어서는 안 됩니다.
+ 뷰의 선택 목록에 집계, 창 함수 또는 집합 반환 함수가 포함되어서는 안 됩니다.
자동 업데이트 가능 뷰에 업데이트 가능 열과 업데이트 불가능 열이 혼합되어 있을 수 있습니다. 기본 관계의 업데이트 가능한 열에 대한 단순 참조인 경우 열을 업데이트할 수 있습니다. 그렇지 않으면 열은 읽기 전용이며 `INSERT` 또는 `UPDATE` 문이 값을 할당하려고 하면 오류가 발생합니다.
이 모든 조건을 충족하지 않는 보다 복잡한 뷰는 기본적으로 읽기 전용입니다. 시스템은 해당 뷰에서 삽입, 업데이트 또는 삭제를 허용하지 않습니다.
**참고**
해당 뷰에서 삽입, 업데이트 또는 삭제를 수행하는 사용자에게는 뷰에 대한 해당 삽입, 업데이트 또는 삭제 권한이 있어야 합니다. 기본적으로 뷰의 소유자는 기본 관계에 대한 관련 권한을 가지고 있어야 하지만 업데이트를 수행하는 사용자는 기본 관계에 대한 권한이 필요하지 않습니다. 그러나 뷰에 security\$1invoker가 true로 설정된 경우 뷰 소유자가 아닌 업데이트를 수행하는 사용자에게 기본 관계에 대한 관련 권한이 있어야 합니다.
## 예제
모든 코미디 영화로 구성된 뷰를 생성합니다.
```
CREATE VIEW comedies AS
SELECT *
FROM films
WHERE kind = 'Comedy';
```
`LOCAL CHECK OPTION`을 포함하여 뷰를 생성합니다.
```
CREATE VIEW pg_comedies AS
SELECT *
FROM comedies
WHERE classification = 'PG'
WITH CASCADED CHECK OPTION;
```
재귀 뷰를 생성합니다.
```
CREATE RECURSIVE VIEW public.nums_1_100 (n) AS
VALUES (1)
UNION ALL
SELECT n+1 FROM nums_1_100 WHERE n < 100;
```
## 호환성
`CREATE OR REPLACE VIEW`는 PostgreSQL 언어 확장입니다. `WITH ( ... )` 절도 확장이며 보안 장벽 뷰 및 보안 호출자 뷰도 마찬가지입니다. Aurora DSQL은 이러한 언어 확장을 지원합니다.
# `ALTER VIEW`
`ALTER VIEW` 문을 사용하면 기존 뷰의 다양한 속성을 변경할 수 있으며 Aurora DSQL은 이 명령에 대한 모든 PostgreSQL 구문을 지원합니다.
## 지원되는 구문
```
ALTER VIEW [ IF EXISTS ] name ALTER [ COLUMN ] column_name SET DEFAULT expression
ALTER VIEW [ IF EXISTS ] name ALTER [ COLUMN ] column_name DROP DEFAULT
ALTER VIEW [ IF EXISTS ] name OWNER TO { new_owner | CURRENT_ROLE | CURRENT_USER | SESSION_USER }
ALTER VIEW [ IF EXISTS ] name RENAME [ COLUMN ] column_name TO new_column_name
ALTER VIEW [ IF EXISTS ] name RENAME TO new_name
ALTER VIEW [ IF EXISTS ] name SET SCHEMA new_schema
ALTER VIEW [ IF EXISTS ] name SET ( view_option_name [= view_option_value] [, ... ] )
ALTER VIEW [ IF EXISTS ] name RESET ( view_option_name [, ... ] )
```
## 설명
`ALTER VIEW`는 뷰의 다양한 보조 속성을 변경합니다. (뷰의 정의 쿼리를 수정하려면 `CREATE OR REPLACE VIEW`를 사용합니다.) `ALTER VIEW`를 사용하려면 뷰를 소유해야 합니다. 뷰의 스키마를 변경하려면 새 스키마에 대한 `CREATE` 권한도 있어야 합니다. 소유자를 변경하려면 새 소유 역할에 `SET ROLE`을 수행할 수 있어야 하며 해당 역할에 뷰의 스키마에 대한 `CREATE` 권한이 있어야 합니다.
## 파라미터
**`name`**
기존 뷰의 이름(선택적으로 스키마 지정)입니다.
**`column_name`**
기존 열의 이름 또는 기존 열의 새 이름입니다.
**`IF EXISTS`**
뷰가 없는 경우 오류가 발생하지 않습니다. 이 경우 알림이 발행됩니다.
**`SET/DROP DEFAULT`**
이러한 양식은 열의 기본값을 설정하거나 제거합니다. 뷰 열의 기본값은 대상이 뷰인 `INSERT` 또는 `UPDATE` 명령으로 대체됩니다.
**`new_owner`**
뷰의 새 소유자의 사용자 이름입니다.
**`new_name`**
새 뷰의 이름입니다.
**`new_schema`**
뷰의 새 스키마입니다.
**`SET ( view_option_name [= view_option_value] [, ... ] )`**
뷰 옵션을 설정합니다. 지원되는 옵션은 다음과 같습니다.
+ `check_option (enum)` - 뷰의 확인 옵션을 변경합니다. 값은 `local` 또는 `cascaded`여야 합니다.
+ `security_barrier (boolean)` - 뷰의 보안 장벽 속성을 변경합니다.
+ `security_invoker (boolean)` - 뷰의 security-invoker 속성을 변경합니다.
**`RESET ( view_option_name [, ... ] )`**
뷰 옵션을 기본값으로 재설정합니다.
## 예제
`foo` 뷰의 이름을 `bar`로 변경:
```
ALTER VIEW foo RENAME TO bar;
```
업데이트 가능한 뷰에 기본 열 값을 연결:
```
CREATE TABLE base_table (id int, ts timestamptz);
CREATE VIEW a_view AS SELECT * FROM base_table;
ALTER VIEW a_view ALTER COLUMN ts SET DEFAULT now();
INSERT INTO base_table(id) VALUES(1); -- ts will receive a NULL
INSERT INTO a_view(id) VALUES(2); -- ts will receive the current time
```
## 호환성
`ALTER VIEW`는 Aurora DSQL이 지원하는 SQL 표준의 PostgreSQL 확장입니다.
# `DROP VIEW`
`DROP VIEW` 문은 기존 뷰를 제거합니다. Aurora DSQL은 이 명령에 대한 전체 PostgreSQL 구문을 지원합니다.
## 지원되는 구문
```
DROP VIEW [ IF EXISTS ] name [, ...] [ CASCADE | RESTRICT ]
```
## 설명
`DROP VIEW`는 기존 뷰를 삭제합니다. 이 명령을 실행하려면 뷰의 소유자여야 합니다.
## Parameters
**`IF EXISTS`**
뷰가 없는 경우 오류가 발생하지 않습니다. 이 경우 알림이 발행됩니다.
**`name`**
제거할 뷰의 이름(선택적으로 스키마 지정)입니다.
**`CASCADE`**
뷰에 종속된 객체(예: 다른 뷰)와 해당 객체에 종속된 모든 객체가 자동으로 삭제됩니다.
**`RESTRICT`**
종속된 객체가 있는 경우 뷰를 삭제하는 것을 거부합니다. 이 값이 기본값입니다.
## 예제
```
DROP VIEW kinds;
```
## 호환성
이 명령은 SQL 표준을 준수합니다. 단, Aurora DSQL이 지원하는 PostgreSQL 확장인 `IF EXISTS` 옵션을 제외하고 표준에서 명령당 하나의 뷰만 삭제할 수 있습니다.
# PostgreSQL에서 Aurora DSQL로 마이그레이션
Aurora DSQL은 [PostgreSQL과 호환](working-with-postgresql-compatibility.md)되도록 설계되었으며 ACID 트랜잭션, 보조 인덱스, 조인, 표준 DML 작업과 같은 핵심 관계형 기능을 지원합니다. 대부분의 기존 PostgreSQL 애플리케이션은 최소한의 변경으로 Aurora DSQL로 마이그레이션할 수 있습니다.
이 섹션에서는 프레임워크 호환성, 마이그레이션 패턴, 아키텍처 고려 사항을 포함하여 애플리케이션을 Aurora DSQL로 마이그레이션하기 위한 실용적인 지침을 제공합니다.
## 프레임워크 및 ORM 호환성
Aurora DSQL은 표준 PostgreSQL 유선 프로토콜을 사용하므로 PostgreSQL 드라이버 및 프레임워크와 호환됩니다. 대부분의 인기 ORM은 변경 없이 또는 최소한의 변경만으로 Aurora DSQL과 호환됩니다. 참조 구현 및 사용 가능한 ORM 통합은 [Aurora DSQL 어댑터 및 방언](aws-sdks.md#aurora-dsql-adapters) 섹션을 참조하세요.
## 일반적인 마이그레이션 패턴
PostgreSQL에서 Aurora DSQL로 마이그레이션할 때 일부 기능은 다르게 작동하거나 대체 구문이 있습니다. 이 섹션에서는 일반적인 마이그레이션 시나리오에 대한 지침을 제공합니다.
### DDL 작업 대안
Aurora DSQL은 기존 PostgreSQL DDL 작업에 대한 최신 대안을 제공합니다.
**인덱스 생성**
비차단 인덱스를 생성하는 데 `CREATE INDEX` 대신 `CREATE INDEX ASYNC`를 사용합니다.
**이점:** 큰 테이블에서 가동 중지 시간 없이 인덱스를 생성할 수 있습니다.
**데이터 제거**
`TRUNCATE` 대신 `DELETE FROM table_name`를 사용합니다.
**대안:** 테이블을 완전히 다시 생성하려면 `DROP TABLE`을 사용한 후 `CREATE TABLE`을 사용합니다.
**시스템 구성**
Aurora DSQL은 완전 관리형이므로 구성이 워크로드 패턴에 따라 자동으로 처리됩니다. AWS Management Console 또는 API를 사용하여 클러스터 설정을 관리합니다.
**이점:** 데이터베이스 튜닝이나 파라미터 관리가 필요하지 않습니다.
### 스키마 설계 패턴
Aurora DSQL과의 호환성을 위해 다음과 같은 일반적인 PostgreSQL 패턴을 조정합니다.
**참조 무결성 패턴**
Aurora DSQL은 테이블 관계 및 `JOIN` 작업을 지원합니다. 참조 무결성을 위해 애플리케이션 계층에서 검증을 구현합니다. 이러한 설계는 애플리케이션 계층 검증을 통해 유연성을 높이고 연쇄적 작업으로 인한 성능 병목 현상을 방지하는 최신 분산 데이터베이스 패턴과 일맥상통합니다.
**패턴:** 일관된 이름 지정 규칙, 검증 로직 및 트랜잭션 경계를 사용하여 애플리케이션 계층에서 참조 무결성 검사를 구현하세요. 많은 대규모 애플리케이션은 오류 처리 및 성능을 더 잘 제어하기 위해 이 접근 방식을 선호합니다.
**임시 데이터 처리**
임시 테이블 대신 CTE, 하위 쿼리 또는 정리 로직이 포함된 일반 테이블을 사용합니다.
**대안:** 세션별 이름을 가진 테이블을 생성하고 애플리케이션 내에서 정리하세요.
## 아키텍처 차이점 이해
Aurora DSQL의 분산 서버리스 아키텍처는 여러 면에서 기존 PostgreSQL과 의도적으로 다릅니다. 이러한 차이점을 통해 Aurora DSQL은 단순성과 확장성이라는 핵심적인 이점을 제공합니다.
### 간소화된 데이터베이스 모델
**클러스터당 단일 데이터베이스**
Aurora DSQL은 클러스터마다 `postgres`라는 내장 데이터베이스 하나를 제공합니다.
**마이그레이션 팁:** 애플리케이션에서 여러 데이터베이스를 사용하는 경우 논리적 분리를 위해 별도의 Aurora DSQL 클러스터를 생성하거나 단일 클러스터 내에서 스키마를 사용하세요.
**임시 테이블 미지원**
임시 데이터 처리를 위해서는 복잡한 쿼리에 대한 유연한 대안을 제공하는 공통 테이블 표현(CTE) 및 하위 쿼리를 사용해야 합니다.
**대안:** 임시 결과 집합의 경우 `WITH` 절과 함께 CTE를 사용하고, 세션별 데이터의 경우 고유한 이름이 지정된 일반 테이블을 사용할 수 있습니다.
**자동 스토리지 관리**
Aurora DSQL을 사용하면 테이블스페이스 및 수동 스토리지 관리가 필요 없습니다. 스토리지는 데이터 패턴에 따라 자동으로 규모가 조정되고 최적화됩니다.
**이점:** 디스크 공간을 모니터링하거나 스토리지 할당을 계획하거나 테이블스페이스 구성을 관리할 필요가 없습니다.
### 최신 애플리케이션 패턴
Aurora DSQL은 유지 관리성과 성능을 향상시키는 최신 애플리케이션 개발 패턴을 장려합니다.
**데이터베이스 트리거 대신 애플리케이션 수준 로직**
트리거와 같은 기능을 사용하려면 애플리케이션 계층에서 이벤트 기반 로직을 구현합니다.
**마이그레이션 전략:** 트리거 로직을 애플리케이션 코드로 이동하거나, EventBridge와 같은 AWS 서비스와 함께 이벤트 기반 아키텍처를 사용하거나, 애플리케이션 로깅을 통해 감사 추적을 구현하세요.
**데이터 처리를 위한 SQL 함수**
Aurora DSQL은 SQL 기반 함수를 지원하지만 PL/pgSQL과 같은 절차적 언어는 지원하지 않습니다.
**대안:** 데이터 변환에 SQL 함수를 사용하거나, 복잡한 로직을 애플리케이션 계층 또는 AWS Lambda 함수로 이동하세요.
**수동적 잠금 대신 낙관적 동시성 제어**
Aurora DSQL은 기존 데이터베이스 잠금 메커니즘과 다른, 잠금 없는 방식인 낙관적 동시성 제어(OCC)를 사용합니다. Aurora DSQL은 다른 트랜잭션을 차단하는 잠금을 획득하는 대신 차단 없이 트랜잭션이 진행되도록 하고 커밋 시 충돌을 감지합니다. 이를 통해 교착 상태를 방지하고 느린 트랜잭션이 다른 작업을 차단하는 것을 막습니다.
**주요 차이점:** Aurora DSQL은 충돌이 발생할 경우 트랜잭션이 잠금을 기다리도록 하는 대신 직렬화 오류를 반환합니다. 이를 위해 애플리케이션이 기존 데이터베이스에서 잠금 제한 시간을 처리하는 것과 유사하게 재시도 로직을 구현해야 하지만, 충돌이 즉시 해결되어 차단 대기를 유발하지 않습니다.
**설계 패턴:** 재시도 메커니즘을 갖춘 멱등성 트랜잭션 로직을 구현하세요. 무작위 프라이머리 키를 사용하고 키 범위 전체에 걸쳐 업데이트를 분산시켜 경합을 최소화하도록 스키마를 설계합니다. 자세한 내용은 [Aurora DSQL의 동시성 제어](working-with-concurrency-control.md)을 참조하세요.
**관계 및 참조 무결성**
Aurora DSQL은 ` JOIN ` 연산을 포함한 테이블 간의 외래 키 관계를 지원합니다. 참조 무결성을 위해 애플리케이션 계층에서 검증을 구현합니다. 참조 무결성을 적용하는 것은 중요할 수 있지만 연쇄적 작업(예: 연쇄 삭제)은 예기치 않은 성능 문제를 일으킬 수 있습니다. 예를 들어, 1,000개의 품목이 있는 주문을 삭제하는 경우 1,001개의 행을 처리하는 트랜잭션이 실행됩니다. 이러한 이유로 많은 고객이 외래 키 제약 조건을 피합니다.
**설계 패턴:** 애플리케이션 계층에서 참조 무결성 검사를 구현하거나, 최종 일관성 패턴을 사용하거나, AWS 서비스를 활용하여 데이터를 검증하세요.
### 운영 간소화
Aurora DSQL을 사용하면 기존 데이터베이스 유지 관리 작업이 대부분 필요 없어지므로 운영 오버헤드가 줄어듭니다.
**수동 유지 관리 불필요**
Aurora DSQL은 스토리지 최적화, 통계 수집 및 성능 튜닝을 자동으로 관리합니다. `VACUUM`과 같은 기존 유지 관리 명령은 시스템에서 처리합니다.
**이점:** 데이터베이스 유지 관리 기간, vacuum 예약 및 시스템 파라미터 튜닝이 필요 없어집니다.
**자동 파티셔닝 및 규모 조정**
Aurora DSQL은 액세스 패턴에 따라 데이터를 자동으로 파티셔닝하고 배포합니다. 최적의 배포를 위해 UUID 또는 애플리케이션 생성 ID를 사용합니다.
**마이그레이션 팁:** 수동 파티셔닝 로직을 제거하고 Aurora DSQL이 데이터 배포를 처리하도록 하세요. 최적의 배포를 위해 UUID 또는 애플리케이션 생성 ID를 사용합니다. 애플리케이션에 순차적 식별자가 필요한 경우 [시퀀스 및 자격 증명 열](sequences-identity-columns.md) 섹션을 참조하세요.
# AI 도구를 사용한 에이전틱 마이그레이션
AI 코딩 에이전트는 기본 제공 안전 검사를 통해 스키마를 분석하고, 코드를 변환하고, DDL 마이그레이션을 실행하여 Aurora DSQL로의 마이그레이션을 가속화할 수 있습니다.
## 마이그레이션에 Kiro 사용
[Kiro](https://kiro.dev/)와 같은 코딩 에이전트는 PostgreSQL 코드를 분석하고 Aurora DSQL로 마이그레이션하는 데 도움이 될 수 있습니다.
+ **스키마 분석:** 기존 스키마 파일을 업로드하고 Kiro에게 잠재적 호환성 문제를 식별하고 대안을 제안하도록 요청하세요.
+ **코드 변환:** 애플리케이션 코드를 제공하고 Kiro에게 트리거 로직을 리팩터링하거나, 시퀀스를 UUID로 대체하거나, 트랜잭션 패턴을 수정하도록 요청하세요.
+ **마이그레이션 계획:** Kiro에게 특정 애플리케이션 아키텍처를 기반으로 단계별 마이그레이션 계획을 생성하도록 요청하세요.
+ **DDL 마이그레이션:** 기본 제공 안전 검사 및 사용자 확인과 함께 테이블 다시 만들기 패턴을 사용하여 스키마 수정 실행
**프롬프트 예제:**
```
"Analyze this PostgreSQL schema for DSQL compatibility and suggest alternatives for any unsupported features"
"Help me refactor this trigger function into application-level logic for DSQL migration"
"Create a migration checklist for moving my Django application from PostgreSQL to DSQL"
"Drop the legacy_status column from the orders table"
"Change the price column from VARCHAR to DECIMAL in the products table"
```
## 테이블 다시 만들기를 사용한 DDL 마이그레이션
Aurora DSQL MCP 서버에서 AI 에이전트를 사용하는 경우, 특정 ALTER TABLE 작업은 데이터를 안전하게 마이그레이션하는 *테이블 다시 만들기 패턴*을 사용합니다. 에이전트는 각 단계에서 정보를 계속 제공하면서 복잡성을 처리합니다.
다음 작업은 테이블 다시 만들기 패턴을 사용합니다.
| 연산 | 접근 방식 |
| --- | --- |
| DROP COLUMN | 새 테이블에서 열 제외 |
| ALTER COLUMN TYPE | 마이그레이션 중 데이터 유형 캐스팅 |
| ALTER COLUMN SET/DROP NOT NULL | 새 테이블 정의의 제약 조건 변경 |
| ALTER COLUMN SET/DROP DEFAULT | 새 테이블 정의에서 기본값 정의 |
| ADD/DROP CONSTRAINT | 새 테이블에 제약 포함 또는 제거 |
| MODIFY PRIMARY KEY | 고유성 검증을 사용하여 새 PK 정의 |
| 열 분할/병합 | SPLIT\$1PART, SUBSTRING 또는 CONCAT 사용 |
다음 ALTER TABLE 작업은 테이블 다시 만들기 없이 직접 지원됩니다.
+ `ALTER TABLE ... RENAME COLUMN` – 열 이름 바꾸기
+ `ALTER TABLE ... RENAME TO` – 테이블 이름 바꾸기
+ `ALTER TABLE ... ADD COLUMN` – 새 열 추가
**안전 기능:** DDL 마이그레이션을 실행할 때 AI 에이전트는 마이그레이션 계획을 제시하고, 데이터 호환성을 확인하고, 행 수를 확인하고, DROP TABLE과 같은 파괴적인 작업을 수행하기 전에 명시적 승인을 요청합니다.
**배치 마이그레이션**: 행이 3,000개를 초과하는 테이블의 경우 에이전트는 트랜잭션 한도 내에서 유지되도록 500\$11,000개의 행 증분으로 마이그레이션을 자동으로 배치화합니다.
## Aurora DSQL MCP 서버
Aurora DSQL Model Context Protocol(MCP) 서버를 사용하면 AI 어시스턴트가 Aurora DSQL 클러스터에 직접 연결하고 Aurora DSQL 설명서를 검색할 수 있습니다. 이를 통해 AI는 다음을 수행할 수 있습니다.
+ 기존 스키마 분석 및 마이그레이션 변경 사항 제안
+ 테이블 다시 만들기 패턴을 사용하여 DDL 마이그레이션 실행
+ 마이그레이션 중 쿼리 테스트 및 호환성 확인
+ 최신 Aurora DSQL 설명서를 기반으로 정확한 최신 지침 제공
Aurora DSQL MCP 서버를 AI 어시스턴트와 함께 사용하려면 [Aurora DSQL MCP 서버](SECTION_aurora-dsql-mcp-server.md)의 설정 지침을 참조하세요.
## PostgreSQL 호환성을 위한 Aurora DSQL 고려 사항
Aurora DSQL은 분산 아키텍처, 서버리스 운영 및 자동 규모 조정을 가능하게 하는 기능 지원 측면에서 자체 관리형 PostgreSQL과 차이가 있습니다. 대부분의 애플리케이션은 이러한 차이점에도 불구하고 수정 없이 작동합니다.
일반적인 고려 사항은 [Amazon Aurora DSQL 사용에 대한 고려 사항](considerations.md) 섹션을 참조하세요. 할당량 및 한도는 [Amazon Aurora DSQL의 클러스터 할당량 및 데이터베이스 한도](CHAP_quotas.md) 섹션을 참조하세요.
+ Aurora DSQL은 클러스터당 `postgres`라는 단일 내장 데이터베이스를 사용합니다. 논리적 분리를 위해 별도의 Aurora DSQL 클러스터를 만들거나 단일 클러스터 내에서 스키마를 사용합니다.
+ `postgres` 데이터베이스는 광범위한 국제 문자 지원을 제공하는 UTF-8 문자 인코딩을 사용합니다.
+ 데이터베이스는 `C` 데이터 정렬만 사용합니다.
+ Aurora DSQL은 `UTC`를 시스템 시간대로 사용합니다. Postgres는 모든 시간대 인식 날짜 및 시간을 UTC로 내부적으로 저장합니다. `TimeZone` 구성 파라미터를 설정하여 클라이언트에 표시되는 방식을 변환하고 서버가 UTC로 내부적으로 변환하는 데 사용할 클라이언트 입력의 기본값으로 사용할 수 있습니다.
+ 트랜잭션 격리 수준은 PostgreSQL `Repeatable Read`에서 고정됩니다.
+ 트랜잭션의 제약 조건은 다음과 같습니다.
+ DDL 및 DML 작업에는 별도의 트랜잭션이 필요합니다.
+ 하나의 트랜잭션에는 DDL 문이 하나만 포함될 수 있습니다.
+ 하나의 트랜잭션은 보조 인덱스 수와 관계없이 최대 3,000개의 행을 수정할 수 있습니다.
+ 행 3,000개 한도는 모든 DML 문(`INSERT`, `UPDATE`, `DELETE`)에 적용됩니다.
+ 데이터베이스 연결은 1시간 후에 시간 초과됩니다.
+ Aurora DSQL은 스키마 수준 권한 부여를 통해 권한을 관리합니다. 관리자 사용자는 `CREATE SCHEMA`를 사용하여 스키마를 만들고 `GRANT USAGE ON SCHEMA`를 사용하여 액세스 권한을 부여합니다. 관리자 사용자는 퍼블릭 스키마에서 객체를 관리하는 반면, 관리자가 아닌 사용자는 명확한 소유권 경계를 위해 사용자가 만든 스키마에서 객체를 만듭니다. 자세한 내용은 [데이터베이스 역할이 데이터베이스에서 SQL을 사용하도록 권한 부여](using-database-and-iam-roles.md#using-database-and-iam-roles-custom-database-roles-sql) 섹션을 참조하세요.
## 마이그레이션에 도움이 필요하세요?
마이그레이션에 중요하지만 현재 Aurora DSQL에서 지원되지 않는 기능이 있는 경우 [Amazon Aurora DSQL에 대한 피드백 제공](providing-feedback.md)에서 AWS와 피드백을 공유하는 방법에 대한 정보를 참조하세요.