Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Arbeiten mit SQL Postgre-Funktionen, die von Amazon RDS für Postgre unterstützt werden SQL
Amazon RDS for Postgre SQL unterstützt viele der gängigsten Postgre-FunktionenSQL. Postgre SQL verfügt beispielsweise über eine Autovacuum-Funktion, die routinemäßige Wartungsarbeiten an der Datenbank durchführt. Die Autovakuierungsfunktion ist standardmäßig aktiviert. Obwohl Sie diese Funktion deaktivieren können, empfehlen wir dringend, sie eingeschaltet zu lassen. Diese Funktion zu verstehen und zu verstehen, was Sie tun können, um sicherzustellen, dass sie ordnungsgemäß funktioniert, ist für jeden eine grundlegende Aufgabe. DBA Weitere Informationen zur Selbstbereinigung finden Sie unter Arbeiten mit dem SQL Postgre-Autovakuum auf Amazon RDS für Postgre SQL. Um mehr über andere allgemeine DBA Aufgaben zu erfahren,Häufige DBA-Aufgaben für Amazon RDS for PostgreSQL.
RDSfor Postgre unterstützt SQL auch Erweiterungen, die der DB-Instance wichtige Funktionen hinzufügen. Sie können beispielsweise die GIS Post-Erweiterung verwenden, um mit räumlichen Daten zu arbeiten, oder die Erweiterung pg_cron verwenden, um Wartungsarbeiten innerhalb der Instanz zu planen. Weitere Hinweise zu Postgre-Erweiterungen finden Sie unter. SQL Verwenden von SQL Postgre-Erweiterungen mit Amazon RDS for Postgre SQL
Foreign Data Wrapper sind ein spezieller Erweiterungstyp, mit dem Ihre RDS for SQL Postgre-DB-Instance mit anderen kommerziellen Datenbanken oder Datentypen funktioniert. Weitere Hinweise zu Fremddaten-Wrappern, die von RDS for Postgre unterstützt werden, finden Sie unter. SQL Arbeiten mit den unterstützten Foreign Data Wrappern für RDS SQL
Im Folgenden finden Sie Informationen zu einigen anderen Funktionen, die von RDS for Postgre unterstützt werden. SQL
Themen
- Benutzerdefinierte Datentypen und Aufzählungen mit for Postgre RDS SQL
- Ereignisauslöser für Postgre RDS SQL
- Riesige Seiten RDS für Postgre SQL
- Durchführen einer logischen Replikation für Amazon RDS for Postgre SQL
- RAMFestplatte für das stats_temp_directory
- Tablespaces für Postgre RDS SQL
- RDSfür Postgre-Kollationen für und andere Mainframe-Migrationen SQL EBCDIC
Benutzerdefinierte Datentypen und Aufzählungen mit for Postgre RDS SQL
Postgre SQL unterstützt das Erstellen benutzerdefinierter Datentypen und das Arbeiten mit Aufzählungen. Weitere Informationen zum Erstellen von und Arbeiten mit Aufzählungen und anderen Datentypen finden Sie in der Postgre-Dokumentation unter Aufzählungstypen
Im Folgenden finden Sie ein Beispiel für das Erstellen eines Typs als Aufzählung und das anschließende Einfügen von Werten in eine Tabelle.
CREATE TYPE rainbow AS ENUM ('red', 'orange', 'yellow', 'green', 'blue', 'purple');
CREATE TYPE
CREATE TABLE t1 (colors rainbow);
CREATE TABLE
INSERT INTO t1 VALUES ('red'), ( 'orange');
INSERT 0 2
SELECT * from t1;
colors -------- red orange (2 rows)
postgres=>
ALTER TYPE rainbow RENAME VALUE 'red' TO 'crimson';
ALTER TYPE
postgres=>
SELECT * from t1;
colors --------- crimson orange (2 rows)
Ereignisauslöser für Postgre RDS SQL
Alle aktuellen SQL Postgre-Versionen unterstützen Ereignisauslöser, ebenso wie alle verfügbaren Versionen von RDS for Postgre. SQL Sie können das Hauptbenutzerkonto nutzen (Standard, postgres
), um Ereignisauslöser zu erstellen, zu ändern, umzubenennen und zu löschen. Ereignisauslöser befinden sich auf DB-Instance-Level und können so auf alle Datenbanken einer Instance angewendet werden.
Der folgende Code erstellt beispielsweise einen Event-Trigger, der den aktuellen Benutzer am Ende jedes Data Definition Language (DDL) -Befehls ausgibt.
CREATE OR REPLACE FUNCTION raise_notice_func() RETURNS event_trigger LANGUAGE plpgsql AS $$ BEGIN RAISE NOTICE 'In trigger function: %', current_user; END; $$; CREATE EVENT TRIGGER event_trigger_1 ON ddl_command_end EXECUTE PROCEDURE raise_notice_func();
Weitere Informationen zu SQL Postgre-Ereignisauslösern finden Sie unter Ereignisauslöser
Es gibt mehrere Einschränkungen bei der Verwendung von SQL Postgre-Event-Triggern bei AmazonRDS. Diese umfassen u. a. folgende:
-
Auf Read Replicas können keine Ereignisauslöser erstellt werden. Sie können jedoch Ereignisauslöser auf einer Read Replica-Quelle erstellen. Die Ereignisauslöser werden dann in die Read Replica kopiert. Die Ereignisauslöser auf der Read Replica werden nicht bei Änderungen, die von der Quelle ausgehen, ausgelöst. Wenn jedoch die Read Replica verwendet wird, werden die vorhandenen Ereignisauslöser bei Datenbank-Operationen ausgelöst.
-
Um ein Hauptversions-Upgrade für eine SQL Postgre-DB-Instance durchzuführen, die Ereignisauslöser verwendet, stellen Sie sicher, dass Sie die Ereignisauslöser löschen, bevor Sie die Instance aktualisieren.
Riesige Seiten RDS für Postgre SQL
Huge Pages ist eine Arbeitsspeicher-Verwaltungsfunktion, die den Overhead reduziert, wenn eine DB-Instance mit großen, zusammenhängenden Arbeitsspeicherblöcken arbeitet, wie sie von gemeinsam genutzten Puffern verwendet werden. Diese SQL Postgre-Funktion wird von allen derzeit RDS für SQL Postgre verfügbaren Versionen unterstützt. Sie können große Seiten für Ihre Anwendung zuordnen, indem Sie Aufrufe des freigegebenen Speichers mmap
oder SYSV
verwenden. RDSfor Postgre SQL unterstützt sowohl Seitengrößen von 4 KB als auch 2 MB.
Sie können Huge Pages ein- oder ausschalten, indem Sie den Wert des huge_pages
-Parameters ändern. Die Funktion ist standardmäßig für alle DB-Instance-Klassen aktiviert, außer Micro, Small und Medium.
RDSfor Postgre SQL verwendet riesige Seiten, die auf dem verfügbaren gemeinsamen Speicher basieren. Wenn die DB-Instance aufgrund von Einschränkungen des gemeinsamen Speichers keine riesigen Seiten verwenden kann, RDS verhindert Amazon den Start der DB-Instance. In diesem Fall RDS setzt Amazon den Status der DB-Instance auf einen Status mit inkompatiblen Parametern. In diesem Fall können Sie den huge_pages
Parameter auf setzen, off
damit Amazon RDS die DB-Instance starten kann.
Der Parameter shared_buffers
ist wichtig für die Einstellung des gemeinsam genutzten Speicherpools, der für die Verwendung von großen Seiten erforderlich ist. Der Standardwert für den shared_buffers
-Parameter verwendet ein Makro für Datenbankparameter. Dieses Makro legt einen Prozentsatz der insgesamt verfügbaren 8 KB an Seiten fest, die für den Speicher der DB-Instance verfügbar sind, verfügbar. Wenn Sie riesige Seiten verwenden, werden diese Seiten in den riesigen Seiten zusammengefasst zugeordnet. Amazon RDS versetzt eine DB-Instance in einen Zustand mit inkompatiblen Parametern, wenn die Shared-Memory-Parameter so eingestellt sind, dass sie mehr als 90 Prozent des DB-Instance-Speichers beanspruchen.
Weitere Informationen zur SQL Postgre-Speicherverwaltung finden Sie unter Ressourcenverbrauch
Durchführen einer logischen Replikation für Amazon RDS for Postgre SQL
Ab Version 10.4 SQL unterstützt RDS for Postgre die Veröffentlichungs- und SQL Abonnement-Syntax, die in Postgre 10 eingeführt wurde. SQL Weitere Informationen finden Sie unter Logische Replikation
Anmerkung
Neben der systemeigenen Funktion zur SQL logischen Replikation von Postgre, die in Postgre SQL 10 eingeführt wurde, unterstützt RDS for Postgre SQL auch die Erweiterung. pglogical
Weitere Informationen finden Sie unter Verwenden von pglogical, um Daten zwischen Instances zu synchronisieren.
Im Folgenden finden Sie Informationen zum Einrichten der logischen Replikation RDS für eine SQL Postgre-DB-Instance.
Themen
Verständnis der logischen Replikation und logischen Decodierung
RDSfor Postgre SQL unterstützt das Streaming von Write-Ahead-Log (WAL) -Änderungen mithilfe der logischen Replikationssteckplätze von SQL Postgre. Es unterstützt auch die Verwendung logischer Decodierung. Sie können logische Replikations-Slots in Ihrer Instance einrichten und über diese Slots Datenbankänderungen auf einen Client wie z. B. streame pg_recvlogical
. Sie erstellen logische Replikationsslots auf Datenbankebene, die Replikationsverbindungen zu einer einzelnen Datenbank unterstützen.
Die gängigsten Clients für die SQL logische Postgre-Replikation sind AWS Database Migration Service ein individuell verwalteter Host auf einer EC2 Amazon-Instance. Der logische Replikations-Slot enthält keine Informationen über den Empfänger des Streams. Es gibt auch keine Anforderung, dass das Ziel eine Replikatdatenbank sein muss. Wenn beim Einrichten eines Slots für die logische Replikation nicht vom Slot gelesen wird, können Daten in den Speicher Ihrer DB-Instance geschrieben werden und diesen schnell füllen.
Sie aktivieren die SQL logische Postgre-Replikation und logische Dekodierung für Amazon RDS mit einem Parameter, einem Replikationsverbindungstyp und einer Sicherheitsrolle. Der Client für die logische Dekodierung kann jeder Client sein, der eine Replikationsverbindung zu einer Datenbank auf einer SQL Postgre-DB-Instance herstellen kann.
Um die logische Dekodierung für eine Postgre-DB-Instance RDS zu aktivieren SQL
-
Stellen Sie sicher, dass das Benutzerkonto, das Sie verwenden, folgende Rollen hat:
-
Die
rds_superuser
-Rolle, damit Sie die logische Replikation aktivieren können -
Die
rds_replication
-Rolle erteilt Berechtigungen zur Verwaltung von logischen Slots und zum Streamen von Daten mithilfe von logischen Slots
-
-
Setzen Sie den statischen Parameter
rds.logical_replication
auf 1. Setzen Sie bei der Anwendung dieses Parameters auch die Parameterwal_level
,max_wal_senders
,max_replication_slots
undmax_connections
fest. Diese Parameteränderungen können die WAL Generierung erhöhen. Legen Sie denrds.logical_replication
Parameter daher nur fest, wenn Sie logische Steckplätze verwenden. -
Starten Sie die DB-Instance neu, damit der statische Parameter
rds.logical_replication
in Kraft tritt. -
Erstellen Sie einen logischen Replikationsslot wie im nächsten Abschnitt erläutert. Für diesen Prozess ist es erforderlich, dass Sie ein Decodier-Plugin angeben. Derzeit SQL unterstützt RDS for Postgre die im Lieferumfang von Postgre enthaltenen Ausgabe-Plugins test_decoding und wal2json. SQL
Arbeiten mit logischen Replikations-Slots
Sie können SQL Befehle verwenden, um mit logischen Steckplätzen zu arbeiten. Mit dem folgenden Befehl wird beispielsweise ein logischer Slot erstellt, der test_slot
mithilfe des SQL Standard-Postgre-Ausgabe-Plug-ins test_decoding
benannt wird.
SELECT * FROM pg_create_logical_replication_slot('test_slot', 'test_decoding');
slot_name | xlog_position -----------------+--------------- regression_slot | 0/16B1970 (1 row)
Mit dem folgenden Befehl können Sie die logischen Slots auflisten.
SELECT * FROM pg_replication_slots;
Mit dem folgenden Befehl können Sie einen logischen Slot entfernen.
SELECT pg_drop_replication_slot('test_slot');
pg_drop_replication_slot ----------------------- (1 row)
Weitere Beispiele für die Arbeit mit logischen Replikationssteckplätzen finden Sie in der SQL Postgre-Dokumentation unter Beispiele für logische Dekodierung
Sobald Sie den logischen Replikationsslot erstellt haben, können Sie mit dem Streaming beginnen. Das folgende Beispiel zeigt, wie die logische Decodierung über das Streaming-Replikationsprotokoll gesteuert wird. In diesem Beispiel wird das Programm pg_recvlogical verwendet, das in der Postgre-Distribution enthalten ist. SQL Dazu muss die Client-Authentifizierung so eingerichtet sein, dass Replikationsverbindungen zugelassen werden.
pg_recvlogical -d postgres --slot test_slot -U postgres --host -
instance-name.111122223333
.aws-region
.rds.amazonaws.com -f - --start
Fragen Sie die Funktion pg_replication_origin_status
ab, um den Inhalt der pg_show_replication_origin_status
Ansicht anzuzeigen.
SELECT * FROM pg_show_replication_origin_status();
local_id | external_id | remote_lsn | local_lsn ----------+-------------+------------+----------- (0 rows)
RAMFestplatte für das stats_temp_directory
Sie können den SQL Parameter RDS for Postgre verwenden, rds.pg_stat_ramdisk_size
um den Systemspeicher anzugeben, der einer RAM Festplatte zum Speichern von Postgre zugewiesen ist. SQL stats_temp_directory
Der RAM Festplattenparameter ist nur in RDS SQL Postgre-Version 14 und niedrigeren Versionen verfügbar.
Bei bestimmten Workloads kann durch die Einstellung dieses Parameters die Leistung verbessert und die I/O-Anforderungen können gesenkt werden. Weitere Informationen zu finden Sie in der stats_temp_directory
Postgre-Dokumentation. SQL
Um eine RAM Festplatte für Ihre einzurichtenstats_temp_directory
, setzen Sie den rds.pg_stat_ramdisk_size
Parameter auf einen ganzzahligen Literalwert in der Parametergruppe, die von Ihrer DB-Instance verwendet wird. Dieser Parameter wird in MB angegeben, daher müssen Sie einen ganzzahligen Wert verwenden. Ausdrücke, Formeln und Funktionen sind für den Parameter rds.pg_stat_ramdisk_size
nicht gültig. Starten Sie die DB-Instance neu, damit die Änderung wirksam wird. Weitere Informationen zum Festlegen von Parametern finden Sie unter Parametergruppen für Amazon RDS.
Mit dem folgenden AWS CLI Befehl wird beispielsweise der RAM Festplattenparameter auf 256 MB festgelegt.
aws rds modify-db-parameter-group \ --db-parameter-group-name pg-95-ramdisk-testing \ --parameters "ParameterName=rds.pg_stat_ramdisk_size, ParameterValue=256, ApplyMethod=pending-reboot"
Nach dem Neustart führen Sie den folgenden Befehl aus, um den Status des stats_temp_directory
anzuzeigen:
postgres=>
SHOW stats_temp_directory;
Der Befehl sollte Folgendes zurückgeben.
stats_temp_directory
---------------------------
/rdsdbramdisk/pg_stat_tmp
(1 row)
Tablespaces für Postgre RDS SQL
RDSfür Postgre SQL unterstützt Tablespaces aus Kompatibilitätsgründen. Da sich der gesamte Speicher auf einem einzigen logischen Volume befindet, können Sie keine Tablespaces für I/O-Splitting oder -Isolierung verwenden. Unsere Benchmarks und Erfahrung zeigen, dass ein einzelnes logisches Volume für die meisten Anwendungsfälle das beste Setup ist.
Um Tablespaces mit Ihrer RDS for Postgre-DB-Instance zu erstellen und zu verwenden, ist die Rolle erforderlichSQL. rds_superuser
Das Hauptbenutzerkonto Ihrer RDS for SQL Postgre-DB-Instance (Standardnamepostgres
) ist Mitglied dieser Rolle. Weitere Informationen finden Sie unter SQLPostgre-Rollen und -Berechtigungen verstehen.
Wenn Sie beim Erstellen eines Tablespace einen Dateinamen angeben, lautet das Pfadpräfix /rdsdbdata/db/base/tablespace
. Im folgenden Beispiel werden Tablespace-Dateien in abgeleg /rdsdbdata/db/base/tablespace/data
. In diesem Beispiel wird angenommen, dass ein dbadmin
-Benutzer (Rolle) existiert und ihm die rds_superuser
-Rolle gewährt wurde, die zur Arbeit mit Tablespaces benötigt wird.
postgres=>
CREATE TABLESPACE act_data OWNER dbadmin LOCATION '/data';
CREATE TABLESPACE
Weitere Informationen zu Postgre-Tablespaces finden Sie unter SQL Tablespaces in der Postgre-Dokumentation
RDSfür Postgre-Kollationen für und andere Mainframe-Migrationen SQL EBCDIC
RDSZu den SQL Postgre-Versionen 10 und höher gehört ICU Version 6.0.2, die auf Unicode 10.0 basiert und Kollationen aus dem Unicode Common Locale Data Repository 32 enthält. CLDR Diese Software-Internationalisierungsbibliotheken stellen sicher, dass Zeichenkodierungen unabhängig vom Betriebssystem oder der Plattform einheitlich dargestellt werden. Weitere Informationen zu Unicode CLDR -32 finden Sie in den Versionshinweisen zu Version CLDR 32
Ab Version 14.3 enthält RDS für Postgre SQL auch Kollationen, die bei der Datenintegration und Konvertierung aus basierten Systemen helfen. EBCDIC Der erweiterte binärkodierte dezimale Austauschcode oder die EBCDICCodierung wird häufig von Mainframe-Betriebssystemen verwendet. Diese von Amazon RDS bereitgestellten Sortierungen sind eng definiert, sodass nur die Unicode-Zeichen sortiert werden, die direkt Codepages zugeordnet sind. EBCDIC Die Zeichen werden in der Reihenfolge der EBCDIC Codepunkte sortiert, um eine Datenvalidierung nach der Konvertierung zu ermöglichen. Diese Sortierungen enthalten weder denormalisierte Formen noch Unicode-Zeichen, die nicht direkt einem Zeichen auf der Quellcodepage zugeordnet sind. EBCDIC
Die Zeichenzuordnungen zwischen EBCDIC Codepages und Unicode-Codepunkten basieren auf Tabellen, die von veröffentlicht wurden. IBM Der komplette Satz steht IBM als komprimierte Datei
-
Unicode to EBCDIC collations table— Einige Mainframe-Datenmigrationstools verwenden LATIN1 oder intern, um Daten zu kodieren und LATIN9 zu verarbeiten. Solche Tools verwenden Roundtrip-Schemata, um die Datenintegrität zu wahren und die umgekehrte Konvertierung zu unterstützen. Die Sortierungen in dieser Tabelle können von Tools verwendet werden, die Daten mithilfe von LATIN1 Kodierung verarbeiten, was keine besondere Behandlung erfordert.
-
Unicode to LATIN9 collations table— Sie können diese Kollationen in jeder beliebigen Datenbank RDS für SQL Postgre verwenden.
In der folgenden Tabelle finden Sie Kollationen, die RDS für Postgre verfügbar sind und Codepages SQL EBCDIC Unicode-Codepunkten zuordnen. Es wird empfohlen, die Sortierungen in dieser Tabelle für die Anwendungsentwicklung zu verwenden, für die eine Sortierung auf der Grundlage der Reihenfolge der IBM Codepages erforderlich ist.
Name der Postgre-Sortierung SQL | Beschreibung der Code-Page-Zuordnung und Sortierreihenfolge |
---|---|
DA-DK-CP277-x-Intensivstation |
Unicode-Zeichen, die direkt der IBM EBCDIC Codepage 277 (gemäß den Konvertierungstabellen) zugeordnet sind, werden in der Reihenfolge der IBM CP 277-Codepunkte sortiert |
de-DE-cp273-x-icu |
Unicode-Zeichen, die direkt der IBM EBCDIC Codepage 273 (gemäß den Konvertierungstabellen) zugeordnet sind, werden in der Reihenfolge der IBM CP 273-Codepunkte sortiert |
en-GB-cp285-x-icu |
Unicode-Zeichen, die direkt der IBM EBCDIC Codepage 285 (gemäß den Konvertierungstabellen) zugeordnet sind, werden in der Reihenfolge der IBM CP 285-Codepunkte sortiert |
en-US-cp037-x-icu |
Unicode-Zeichen, die direkt der IBM EBCDIC Codepage 037 (gemäß den Konvertierungstabellen) zugeordnet sind, werden in der Reihenfolge der IBM CP 37-Codepunkte sortiert |
es-ES-cp284-x-icu |
Unicode-Zeichen, die direkt der IBM EBCDIC Codepage 284 (gemäß den Konvertierungstabellen) zugeordnet sind, werden in der Reihenfolge der IBM CP 284-Codepunkte sortiert |
fi-FI-cp278-x-icu |
Unicode-Zeichen, die direkt der IBM EBCDIC Codepage 278 (gemäß den Konvertierungstabellen) zugeordnet sind, werden in der Reihenfolge der IBM CP 278-Codepunkte sortiert |
fr-FR-cp297-x-icu |
Unicode-Zeichen, die direkt der IBM EBCDIC Codepage 297 (gemäß den Konvertierungstabellen) zugeordnet sind, werden in der Reihenfolge der IBM CP 297-Codepunkte sortiert |
it-IT-cp280-x-icu |
Unicode-Zeichen, die direkt der IBM EBCDIC Codepage 280 (gemäß den Konvertierungstabellen) zugeordnet sind, werden in der Reihenfolge der IBM CP 280-Codepunkte sortiert |
nl-BE-cp500-x-icu |
Unicode-Zeichen, die direkt der IBM EBCDIC Codepage 500 (gemäß den Konvertierungstabellen) zugeordnet sind, werden in der Reihenfolge der IBM CP 500-Codepunkte sortiert |
Amazon RDS bietet eine Reihe zusätzlicher Sortierungen, die Unicode-Codepunkte, die LATIN9 Zeichen anhand der von veröffentlichten Tabellen zugeordnet sindIBM, in der Reihenfolge der ursprünglichen Codepunkte gemäß der EBCDIC Codepage der Quelldaten sortieren.
Name der Postgre-Sortierung SQL | Beschreibung der Code-Page-Zuordnung und Sortierreihenfolge |
---|---|
DA-DK-CP1142 m-x-icu |
Unicode-Zeichen, die den ursprünglich aus der IBM EBCDIC Codepage 1142 (gemäß den Konvertierungstabellen) konvertierten LATIN9 Zeichen zugeordnet sind, werden in der Reihenfolge der CP-1142-Codepunkte sortiert IBM |
DE-DE-CP1141 m-x-icu |
Unicode-Zeichen, die den ursprünglich aus der IBM EBCDIC Codepage 1141 (gemäß den Konvertierungstabellen) konvertierten LATIN9 Zeichen zugeordnet sind, werden in der Reihenfolge der CP-1141-Codepunkte IBM sortiert |
de-GB-CP1146 m-x-icu |
Unicode-Zeichen, die den ursprünglich aus der IBM EBCDIC Codepage 1146 (gemäß den Konvertierungstabellen) konvertierten LATIN9 Zeichen zugeordnet sind, werden in der Reihenfolge der CP-1146-Codepunkte sortiert IBM |
en-US-CP1140 m-x-icu |
Unicode-Zeichen, die den ursprünglich aus der IBM EBCDIC Codepage 1140 (gemäß den Konvertierungstabellen) konvertierten LATIN9 Zeichen zugeordnet sind, werden in IBM der Reihenfolge der CP 1140-Codepunkte sortiert |
es-ES-CP1145 m-x-icu |
Unicode-Zeichen, die den ursprünglich aus der IBM EBCDIC Codepage 1145 (gemäß den Konvertierungstabellen) konvertierten LATIN9 Zeichen zugeordnet sind, werden in der Reihenfolge der CP-1145-Codepunkte IBM sortiert |
fi-FI-CP1143 m-x-icu |
Unicode-Zeichen, die den ursprünglich aus der IBM EBCDIC Codepage 1143 (gemäß den Konvertierungstabellen) konvertierten LATIN9 Zeichen zugeordnet sind, werden in der Reihenfolge der CP-1143-Codepunkte sortiert IBM |
fr-FR-CP1147 m-x-icu |
Unicode-Zeichen, die den ursprünglich aus der IBM EBCDIC Codepage 1147 (gemäß den Konvertierungstabellen) konvertierten LATIN9 Zeichen zugeordnet sind, werden in der Reihenfolge der CP-1147-Codepunkte sortiert IBM |
it-IT-CP1144 m-x-icu |
Unicode-Zeichen, die den ursprünglich aus der IBM EBCDIC Codepage 1144 (gemäß den Konvertierungstabellen) konvertierten LATIN9 Zeichen zugeordnet sind, werden in der Reihenfolge der CP-1144-Codepunkte IBM sortiert |
nl-BE-CP1148 m-x-icu |
Unicode-Zeichen, die den ursprünglich aus der IBM EBCDIC Codepage 1148 (gemäß den Konvertierungstabellen) konvertierten LATIN9 Zeichen zugeordnet sind, werden in der Reihenfolge der CP-1148-Codepunkte sortiert IBM |
Im Folgenden finden Sie ein Beispiel für die Verwendung einer RDS for SQL Postgre-Kollatierung.
db1=>
SELECT pg_import_system_collations('pg_catalog');pg_import_system_collations ----------------------------- 36
db1=>
SELECT '¤' < 'a' col1;col1 ------ t
db1=>
SELECT '¤' < 'a' COLLATE "da-DK-cp277-x-icu" col1;col1 ------ f
Es wird empfohlen, die Sortierungen in den Unicode to EBCDIC collations table und in der für die Anwendungsentwicklung zu verwenden, Unicode to LATIN9 collations table für die eine Sortierung auf der Grundlage der Reihenfolge der IBM Codepages erforderlich ist. Die folgenden Sortierungen (mit dem Suffix „b“) sind auch in sichtbarpg_collation
, sind aber für die Verwendung durch Mainframe-Datenintegrations- und Migrationstools vorgesehen. Sie ordnen Codepages bestimmten Codepunktverschiebungen zu und erfordern eine besondere Behandlung bei AWS der Sortierung. Mit anderen Worten: Die folgenden Sortierungen werden nicht empfohlen.
-
DA-DK-277 b-x-icu
-
DA-DK-1142 b-x-icu
-
DE-DE-CP273 b-x-icu
-
DE-DE-CP1141 b-x-icu
-
de-GB-CP1146 b-x-icu
-
de-GB-CP285 b-x-icu
-
de-US-CP037 b-x-icu
-
de-US-CP1140 b-x-icu
-
es-ES-CP1145 b-x-icu
-
Es-ES-CP284 b-x-icu
-
fi-FI-CP1143 b-x-icu
-
fr-FR-CP1147 b-x-icu
-
fr-FR-CP297 b-x-icu
-
it-IT-CP1144 b-x-icu
-
it-IT-CP280 b-x-icu
-
NL-BE-CP1148 b-x-icu
-
NL-BE-CP500 b-x-icu
Weitere Informationen zur Verwaltung von Kollationen in Postgre SQL finden Sie unter Collation Support