Utilizzo delle caratteristiche di PostgreSQL supportate da Amazon RDS for PostgreSQL

Amazon RDS per PostgreSQL supporta molte delle funzioni PostgreSQL più comuni. Ad esempio, PostgreSQL ha una funzione di pulizia automatica che esegue la manutenzione di routine sul database. La funzione autovacuum è attivata per impostazione predefinita. Sebbene sia possibile disattivare questa caratteristica, è consigliabile tenerla attiva. Comprendere questa funzionalità e cosa puoi fare per assicurarti che funzioni come dovrebbe è un compito di base di qualsiasi DBA. Per ulteriori informazioni sulla caratteristica autovacuum, consulta Utilizzo della funzione di autovacuum di PostgreSQL in Amazon RDS for PostgreSQL. Per ulteriori informazioni su altre attività DBA comuni, Attività DBA comuni per Amazon RDS for PostgreSQL.

RDS for PostgreSQL supporta anche estensioni che aggiungono funzionalità importanti all'istanza database. Ad esempio, è possibile utilizzare l'estensione PostGIS per lavorare con i dati spaziali o utilizzare l'estensione pg_cron per pianificare la manutenzione dall'istanza. Per ulteriori informazioni sulle estensioni PostgreSQL, consulta Utilizzo delle estensioni PostgreSQL con Amazon RDS for PostgreSQL.

I wrapper di dati esterni sono un tipo specifico di estensione progettato per consentire all'istanza database RDS for PostgreSQL di lavorare con altri tipi di dati o database commerciali. Per ulteriori informazioni sui wrapper di dati esterni supportati da RDS for PostgreSQL, consulta Utilizzo dei wrapper di dati esterni supportati per Amazon RDS for PostgreSQL.

Di seguito sono riportate informazioni su alcune altre caratteristiche supportate da RDS per PostgreSQL.

Tipi di dati personalizzati ed enumerazioni con RDS for PostgreSQL

PostgreSQL supporta la creazione di tipi di dati personalizzati e l'utilizzo delle enumerazioni. Per ulteriori informazioni sulla creazione e sull'utilizzo di enumerazioni e altri tipi di dati, consulta Tipi enumerati nella documentazione di PostgreSQL.

Di seguito è riportato un esempio di creazione di un tipo come enumerazione e quindi di inserimento di valori in una tabella.

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)

Trigger di eventi per RDS for PostgreSQL

Tutte le versioni attuali di PostgreSQL supportano i trigger di eventi, così come tutte le versioni disponibili di RDS for PostgreSQL. Puoi utilizzare l'account utente principale (di default postgres) per creare, modificare, rinominare ed eliminare i trigger degli eventi. I trigger di eventi sono a livello di istanza database, quindi possono essere applicati a tutti i database in un'istanza.

Ad esempio, il seguente codice crea un trigger di eventi che stampa l'utente corrente alla fine di ogni comando DDL (Data Definition Language).

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();

Per ulteriori informazioni sui trigger di eventi PostgreSQL, consulta Trigger di eventi nella documentazione di PostgreSQL.

L'utilizzo dei trigger di eventi PostgreSQL su Amazon RDS prevede diverse limitazioni. Questi sono i seguenti:

• Non puoi creare trigger di eventi su repliche di lettura. Tuttavia, puoi creare trigger di eventi su una replica di lettura master. I trigger di eventi vengono quindi copiati nella replica di lettura. I trigger di eventi sulla replica di lettura non vengono attivati sulla replica di lettura in caso di modifiche da parte del master. Tuttavia, se viene promossa la replica di lettura, i trigger di eventi esistenti si attivano in caso di operazioni del database.

• Per eseguire un aggiornamento principale della versione a un'istanza database PostgreSQL che utilizza i trigger di eventi, assicurati di eliminare i trigger di eventi prima dell'aggiornamento dell'istanza.

Pagine di grandi dimensioni per RDS for PostgreSQL

Le pagine di grandi dimensioni sono una caratteristica di gestione della memoria che riduce il sovraccarico quando un'istanza database lavora con grandi blocchi di memoria contigui, come quelli utilizzati dai buffer condivisi. Questa caratteristica di PostgreSQL è supportata da tutte le versioni RDS for PostgreSQL attualmente disponibili. Allocate enormi pagine per la vostra applicazione utilizzando chiamate mmap o SYSV memoria condivisa. RDS for PostgreSQL supporta pagine da 4 KB e 2 MB.

È possibile attivare o disattivare pagine di grandi dimensioni modificando il valore del parametro huge_pages. La caratteristica è attivata per impostazione predefinita per tutte le classi di istanze database diverse dalle classi di istanza micro, small e medium.

RDS for PostgreSQL usa le pagine di grandi dimensioni in base alla memoria condivisa disponibile. Se l'istanza database non è in grado di utilizzare le pagine di grandi dimensioni a causa dei limiti della memoria condivisa, Amazon RDS impedisce l'avvio dell'istanza database. In questo caso, Amazon RDS imposta lo stato dell'istanza database su uno stato dei parametri incompatibile. In questo caso, puoi impostare il parametro huge_pages su off per permettere a Amazon RDS di avviare l'istanza database.

Il parametro shared_buffers è essenziale per impostare il pool della memoria condivisa richiesto per l'utilizzo delle pagine di grandi dimensioni. Il valore predefinito per il parametro shared_buffers utilizza una macro dei parametri del database. Questa macro imposta una percentuale di 8 KB in totale disponibili per la memoria dell'istanza database. Quando si utilizzano pagine di dimensioni enormi, queste pagine vengono allocate insieme alle pagine enormi. Amazon RDS inserisce un'istanza database in uno stato di parametri non compatibile se i parametri della memoria condivisa sono impostati in modo da richiedere più del 90% della memoria dell'istanza database.

Per ulteriori informazioni sulla gestione della memoria PostgreSQL, consulta Consumo di risorse nella documentazione di PostgreSQL.

Esecuzione della replica logica per Amazon RDS for PostgreSQL

A partire dalla versione 10.4, RDS per PostgreSQL supporta la pubblicazione e la sottoscrizione della sintassi SQL introdotta in PostgreSQL 10. Per ulteriori informazioni, consulta Replica logica nella documentazione di PostgreSQL.

Nota

Oltre alla funzionalità di replica logica nativa di PostgreSQL introdotta in PostgreSQL 10, RDS per PostgreSQL supporta anche l'estensione pglogical. Per ulteriori informazioni, consulta Utilizzo di pglogical per sincronizzare i dati tra le istanze.

Di seguito sono riportate informazioni sull'impostazione della replica logica per un'istanza database RDS for PostgreSQL.

Argomenti

• Comprendere la replica logica e la decodifica logica
• Lavorare con gli slot di replica logica

Comprendere la replica logica e la decodifica logica

RDS for PostgreSQL supporta lo streaming delle modifiche write-ahead log (WAL) utilizzando slot di replica logica di PostgreSQL. Supporta inoltre l'utilizzo della decodifica logica. Puoi configurare gli slot di replica logica nell'istanza ed effettuare lo streaming delle modifiche del database tramite questi slot in un client come pg_recvlogical. Gli slot di replica logica sono creati a livello di database e supportano le connessioni di replica a un singolo database.

I client più comuni per la replica logica PostgreSQL sono AWS Database Migration Service o un host gestito personalizzato su un'istanza Amazon EC2. Lo slot di replica logica non contiene informazioni sul ricevitore del flusso. Inoltre, non è necessario che il target sia un database di replica. Se configuri uno slot di replica logica e non leggi lo slot, i dati possono venire scritti e riempire rapidamente lo storage dell'istanza database.

La replica logica e la decodifica logica PostgreSQL in Amazon RDS vengono attivate con un parametro, un tipo di connessione di replica e un ruolo di sicurezza. Il client per la decodifica logica può essere qualsiasi client in grado di stabilire una connessione di replica a un database in un'istanza database PostgreSQL.

Per attivare la decodifica logica per un'istanza database RDS for PostgreSQL

1. Assicurati che l'account utente che stai utilizzando abbia i seguenti ruoli:

   • Il ruolo rds_superuser in modo da poter attivare la replica logica

   • Il ruolo rds_replication per concedere le autorizzazioni per gestire gli slot logici e per eseguire lo streaming dei dati utilizzando gli slot logici

2. Impostare il parametro statico rds.logical_replication su 1. Come parte dell'applicazione di questo parametro, imposta anche i parametri wal_level, max_wal_senders, max_replication_slots e max_connections. Le modifiche di questi parametri possono aumentare la generazione dei WAL, quindi imposta il parametro rds.logical_replication solo quando si utilizzano gli slot logici.

3. Affinché il parametro statico rds.logical_replication abbia effetto, riavviare l'istanza database.

4. Creare uno slot di replica logica come spiegato nella sezione successiva. Questo processo richiede che venga specificato un plug-in di decodifica. Attualmente RDS for PostgreSQL supporta i plugin di output test_decoding e wal2json forniti con PostgreSQL.

Per ulteriori informazioni sulla decodifica logica di PostgreSQL, consulta la documentazione di PostgreSQL.

Lavorare con gli slot di replica logica

Puoi utilizzare i comandi SQL per lavorare con gli slot logici. Ad esempio, il seguente comando crea uno slot logico denominato test_slot che utilizza il plugin di output PostgreSQL predefinito test_decoding test_decoding.

SELECT * FROM pg_create_logical_replication_slot('test_slot', 'test_decoding');
slot_name    | xlog_position
-----------------+---------------
regression_slot | 0/16B1970
(1 row)

Per elencare gli slot logici, utilizza il seguente comando:

SELECT * FROM pg_replication_slots;

Per eliminare uno slot logico, utilizza il seguente comando:

SELECT pg_drop_replication_slot('test_slot');
pg_drop_replication_slot
-----------------------
(1 row)

Per ulteriori esempi su come lavorare con gli slot di replica logica, consulta gli esempi di decodifica logica nella documentazione PostgreSQL.

Una volta creato lo slot di replica logica, puoi iniziare lo streaming. Nell'esempio seguente viene illustrato il modo in cui la decodifica logica viene controllata tramite il protocollo di replica in streaming. Questo esempio utilizza il programma pg_recvlogical, incluso nella distribuzione PostgreSQL. Questa operazione richiede che l'autenticazione del client sia configurata per permettere le connessioni alla replica.

pg_recvlogical -d postgres --slot test_slot -U postgres
    --host -instance-name.111122223333.aws-region.rds.amazonaws.com 
    -f -  --start

Per visualizzare il contenuto della vista pg_replication_origin_status, eseguire una query sulla funzione pg_show_replication_origin_status.

SELECT * FROM pg_show_replication_origin_status();
local_id | external_id | remote_lsn | local_lsn
----------+-------------+------------+-----------
(0 rows)

Disco RAM per stats_temp_directory

Puoi utilizzare il parametro rds.pg_stat_ramdisk_size di RDS for PostgreSQL per specificare la memoria di sistema allocata a un disco RAM per l'archiviazione di stats_temp_directory PostgreSQL. Il parametro del disco RAM è disponibile per tutte le versioni PostgreSQL su Amazon RDS.

Per alcuni carichi di lavoro, l'impostazione di questo parametro può migliorare le prestazioni e ridurre i requisiti I/O. Per ulteriori informazioni su stats_temp_directory, consulta la documentazione di PostgreSQL..

Per impostare un disco RAM per stats_temp_directory, imposta il parametro rds.pg_stat_ramdisk_size su un valore diverso da zero nel gruppo di parametri utilizzato dalla tua istanza database. Questo parametro utilizza MB, quindi è necessario specificare un valore intero. Espressioni, formule e funzioni non sono valide per il parametro rds.pg_stat_ramdisk_size. Assicurati di riavviare l'istanza database in modo da applicare il nuovo valore. Per informazioni sull'estensione dei parametri consulta Utilizzo di gruppi di parametri.

Ad esempio, il seguente comando AWS CLI imposta il parametro del disco RAM su 256 MB.

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"

Dopo il riavvio, esegui il seguente comando per visualizzare lo stato di stats_temp_directory:

postgres=> SHOW stats_temp_directory;

Il comando deve restituire quanto segue.

stats_temp_directory
---------------------------
/rdsdbramdisk/pg_stat_tmp
(1 row)

Spazi tabelle per RDS for PostgreSQL

RDS for PostgreSQL supporta gli spazi tabelle per la compatibilità. Poiché tutto lo storage si trova su un singolo volume logico, non è possibile utilizzare gli spazi tabelle per la suddivisione o l'isolamento di I/O. I nostri benchmark e la nostra esperienza indicano che un singolo volume logico è la configurazione migliore per la maggior parte dei casi d'uso.

Per creare e utilizzare spazi tabelle con l'istanza database di RDS for PostgreSQL occorre il ruolo rds_superuser. L'account utente principale dell'istanza database RDS for PostgreSQL (nome di default, postgres) è un membro di questo ruolo. Per ulteriori informazioni, consulta Informazioni su ruoli e autorizzazioni di PostgreSQL.

Se si specifica un nome di file quando si crea uno spazio tabelle, il prefisso del percorso è /rdsdbdata/db/base/tablespace. Nell'esempio seguente i file dello spazio tabelle vengono posizionati in /rdsdbdata/db/base/tablespace/data. Questo esempio presuppone l'esistenza di un utente (ruolo) dbadmin e la concessione del ruolo rds_superuser necessario per lavorare con gli spazi tabella.

postgres=> CREATE TABLESPACE act_data
  OWNER dbadmin
  LOCATION '/data';
CREATE TABLESPACE

Per ulteriori informazioni sugli spazi tabella PostgreSQL, consulta Spazi tabella nella documentazione di PostgreSQL.

Regole di confronto RDS per PostgreSQL per EBCDIC e altre migrazioni di mainframe

RDS per PostgreSQL versione 10 e successive include la versione 60.2 di ICU, basata su Unicode 10.0 e include le regole di confronto tratte da Unicode Common Locale Data Repository, CLDR 32. Queste librerie di internazionalizzazione del software garantiscono la coerenza a livello di presentazione delle codifiche dei caratteri, indipendentemente dal sistema operativo o dalla piattaforma. Per ulteriori informazioni su Unicode CLDR-32, consulta la Nota di rilascio di CLDR 32 sul sito Web Unicode CLDR. Puoi saperne di più sui componenti di internazionalizzazione per Unicode (ICU) nel sito Web ICU Technical Committee (ICU-TC). Per informazioni su ICU-60, consulta la pagina Download ICU 60.

A partire dalla versione 14.3, RDS per PostgreSQL include anche regole di confronto che facilitano l'integrazione e la conversione dei dati dai sistemi basati su EBCDIC. Il codice di interscambio decimale con codice binario esteso codifica EBCDIC (Extended Binary Coded Decimal Interchange Code) è comunemente utilizzata dai sistemi operativi mainframe. Queste regole di confronto fornite da Amazon RDS sono definite in modo restrittivo per ordinare solo i caratteri Unicode mappati direttamente alle tabelle codici EBCDIC. I caratteri sono ordinati in base all'ordine dei punti di codice EBCDIC per consentire la convalida dei dati dopo la conversione. Queste regole di confronto non includono i moduli denormalizzati, né i caratteri Unicode non associati direttamente a un carattere nella tabella codici EBCDIC di origine.

Le mappature dei caratteri tra le tabelle codici EBCDIC e i punti di codice Unicode si basano su tabelle pubblicate da IBM. Il set completo è disponibile presso IBM come file compresso da scaricare. RDS per PostgreSQL ha utilizzato queste mappature con gli strumenti forniti da ICU per creare le regole di confronto elencate nelle tabelle di questa sezione. I nomi delle regole di confronto includono la lingua e il paese richiesti da ICU. Tuttavia, le tabelle codici EBCDIC non specificano le lingue e alcune tabelle codici EBCDIC coprono più paesi. Ciò significa che la parte relativa alla lingua e al paese dei nomi delle regole di confronto nella tabella è arbitraria e non deve necessariamente corrispondere alla lingua corrente. In altre parole, il numero della tabella codici è la parte più importante del nome della regola di confronto in questa tabella. È possibile utilizzare una qualsiasi delle regole di confronto elencate nelle tabelle seguenti in qualsiasi database RDS per PostgreSQL.

• Unicode to EBCDIC collations table: alcuni strumenti di migrazione dei dati mainframe utilizzano internamente LATIN1 o LATIN9 per codificare ed elaborare i dati. Tali strumenti utilizzano schemi round trip per preservare l'integrità dei dati e supportare la conversione inversa. Le regole di confronto in questa tabella possono essere utilizzate da strumenti che elaborano i dati utilizzando la codifica LATIN1, che non richiede una gestione speciale.

• Unicode to LATIN9 collations table: è possibile utilizzare queste regole di confronto in qualsiasi database RDS per PostgreSQL.

Nella tabella seguente sono disponibili le regole di confronto disponibili in RDS per PostgreSQL che mappano le tabelle codici EBCDIC ai punti di codice Unicode. Si consiglia di utilizzare le regole di confronto contenute in questa tabella per lo sviluppo di applicazioni che richiedono l'ordinamento in base all'ordine delle tabelle codici IBM.

Nome della regola di confronto PostgreSQL	Descrizione della mappatura e dell'ordinamento delle tabelle codici
da-DK-cp277-x-icu	I caratteri Unicode mappati direttamente alla tabella codici IBM EBCDIC 277 (per tabelle di conversione) sono ordinati in base all'ordine dei punti di codice IBM CP 277
de-DE-cp273-x-icu	I caratteri Unicode mappati direttamente alla tabella codici IBM EBCDIC 273 (per tabelle di conversione) sono ordinati in base all'ordine dei punti di codice IBM CP 273
en-GB-cp285-x-icu	I caratteri Unicode mappati direttamente alla tabella codici IBM EBCDIC 285 (per tabelle di conversione) sono ordinati in base all'ordine dei punti di codice IBM CP 285
en-US-cp037-x-icu	I caratteri Unicode mappati direttamente alla tabella codici IBM EBCDIC 037 (per tabelle di conversione) sono ordinati in base all'ordine dei punti di codice IBM CP 37
es-ES-cp284-x-icu	I caratteri Unicode mappati direttamente alla tabella codici IBM EBCDIC 284 (per tabelle di conversione) sono ordinati in base all'ordine dei punti di codice IBM CP 284
fi-FI-cp278-x-icu	I caratteri Unicode mappati direttamente alla tabella codici IBM EBCDIC 278 (per tabelle di conversione) sono ordinati in base all'ordine dei punti di codice IBM CP 278
fr-FR-cp297-x-icu	I caratteri Unicode mappati direttamente alla tabella codici IBM EBCDIC 297 (per tabelle di conversione) sono ordinati in base all'ordine dei punti di codice IBM CP 297
it-IT-cp280-x-icu	I caratteri Unicode mappati direttamente alla tabella codici IBM EBCDIC 280 (per tabelle di conversione) sono ordinati in base all'ordine dei punti di codice IBM CP 280
nl-BE-cp500-x-icu	I caratteri Unicode mappati direttamente alla tabella codici IBM EBCDIC 500 (per tabelle di conversione) sono ordinati in base all'ordine dei punti di codice IBM CP 500

Amazon RDS fornisce una serie di regole di confronto aggiuntive che ordinano i punti di codice Unicode mappati ai caratteri LATIN9 utilizzando le tabelle pubblicate da IBM, nell'ordine dei punti di codice originali in base alla tabella codici EBCDIC dei dati di origine.

Nome della regola di confronto PostgreSQL	Descrizione della mappatura e dell'ordinamento delle tabelle codici
da-DK-cp1142m-x-icu	I caratteri Unicode mappati direttamente ai caratteri LATIN9 originariamente convertiti dalla tabella codici IBM EBCDIC 1142 (per tabelle di conversione) sono ordinati in base all'ordine dei punti di codice IBM CP 1142
de-DE-cp1141m-x-icu	I caratteri Unicode mappati direttamente ai caratteri LATIN9 originariamente convertiti dalla tabella codici IBM EBCDIC 1141 (per tabelle di conversione) sono ordinati in base all'ordine dei punti di codice IBM CP 1141
en-GB-cp1146m-x-icu	I caratteri Unicode mappati direttamente ai caratteri LATIN9 originariamente convertiti dalla tabella codici IBM EBCDIC 1146 (per tabelle di conversione) sono ordinati in base all'ordine dei punti di codice IBM CP 1146
en-US-cp1140m-x-icu	I caratteri Unicode mappati direttamente ai caratteri LATIN9 originariamente convertiti dalla tabella codici IBM EBCDIC 1140 (per tabelle di conversione) sono ordinati in base all'ordine dei punti di codice IBM CP 1140
es-ES-cp1145b-x-icu	I caratteri Unicode mappati direttamente ai caratteri LATIN9 originariamente convertiti dalla tabella codici IBM EBCDIC 1145 (per tabelle di conversione) sono ordinati in base all'ordine dei punti di codice IBM CP 1145
fi-FI-cp1143m-x-icu	I caratteri Unicode mappati direttamente ai caratteri LATIN9 originariamente convertiti dalla tabella codici IBM EBCDIC 1143 (per tabelle di conversione) sono ordinati in base all'ordine dei punti di codice IBM CP 1143
fr-FR-cp1147m-x-icu	I caratteri Unicode mappati direttamente ai caratteri LATIN9 originariamente convertiti dalla tabella codici IBM EBCDIC 1147 (per tabelle di conversione) sono ordinati in base all'ordine dei punti di codice IBM CP 1147
it-IT-cp1144b-x-icu	I caratteri Unicode mappati direttamente ai caratteri LATIN9 originariamente convertiti dalla tabella codici IBM EBCDIC 1144 (per tabelle di conversione) sono ordinati in base all'ordine dei punti di codice IBM CP 1144
nl-BE-cp1148m-x-icu	I caratteri Unicode mappati direttamente ai caratteri LATIN9 originariamente convertiti dalla tabella codici IBM EBCDIC 1148 (per tabelle di conversione) sono ordinati in base all'ordine dei punti di codice IBM CP 1148

Di seguito viene fornito un esempio di come utilizzare una regola di confronto RDS per PostgreSQL.

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

Si consiglia di utilizzare le regole di confronto contenute nella Unicode to EBCDIC collations table e nella Unicode to LATIN9 collations table per lo sviluppo di applicazioni che richiedono l'ordinamento in base all'ordine delle tabelle codici IBM. Le seguenti regole di confronto (con il suffisso "b") sono visibili anche in pg_collation, ma sono destinate all'uso da parte degli strumenti di integrazione e migrazione dei dati mainframe in AWS che mappano le tabelle codici con spostamenti specifici dei punti di codice e richiedono una gestione speciale a livello di regola di confronto. In altre parole, si sconsiglia l'utilizzo delle regole di confronto elencate di seguito.

• da-DK-277b-x-icu

• da-DK-1142b-x-icu

• de-DE-cp273b-x-icu

• de-DE-cp1141b-x-icu

• en-GB-cp1146b-x-icu

• en-GB-cp285b-x-icu

• en-US-cp037b-x-icu

• en-US-cp1140b-x-icu

• es-ES-cp1145b-x-icu

• es-ES-cp284b-x-icu

• fi-FI-cp1143b-x-icu

• fr-FR-cp1147b-x-icu

• fr-FR-cp297b-x-icu

• it-IT-cp1144b-x-icu

• it-IT-cp280b-x-icu

• nl-BE-cp1148b-x-icu

• nl-BE-cp500b-x-icu

Per saperne di più sulla migrazione delle applicazioni da ambienti mainframe ad AWS, consulta la pagina relativa alla modernizzazione dei mainframe AWS.

Per ulteriori informazioni sulla gestione delle regole di confronto in PostgreSQL, consulta la pagina relativa al supporto delle regole di confronto nella documentazione di PostgreSQL.