Utilisation des fonctions PostgreSQL prises en charge par Amazon RDS for PostgreSQL - Amazon Relational Database Service

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Utilisation des fonctions PostgreSQL prises en charge par Amazon RDS for PostgreSQL

Amazon RDS for PostgreSQL prend en charge la plupart des fonctionnalités les plus courantes de PostgreSQL. Par exemple, PostgreSQL dispose d'une fonction d'autovacuum qui effectue une maintenance de routine sur la base de données. La fonction d'autovacuum est active par défaut. Bien que vous puissiez désactiver cette fonction, nous vous recommandons vivement de la conserver active. Comprendre cette fonction et ce que vous pouvez faire pour vous assurer qu'elle fonctionne comme il se doit est une tâche de base de tout DBA. Pour de plus amples informations sur l'autovacuum, veuillez consulter Utilisation de la fonction autovacuum de PostgreSQL sur Amazon RDS for PostgreSQL. Pour en savoir plus sur les autres tâches DBA courantes, Tâches courantes d'administration de bases de données pour Amazon RDS for PostgreSQL.

RDS for PostgreSQL prend également en charge les extensions qui ajoutent des fonctionnalités importantes à l'instance de base de données. Par exemple, vous pouvez utiliser l'extension PostGIS pour travailler avec des données spatiales ou utiliser l'extension pg_cron pour planifier la maintenance depuis l'instance elle-même. Pour plus d'informations sur les extensions PostgreSQL, veuillez consulter Utilisation des extensions PostgreSQL avec Amazon RDS for PostgreSQL.

Les wrappers de données externes sont un type d'extension spécifique conçu pour permettre à votre instance de base de données RDS for PostgreSQL de fonctionner avec d'autres bases de données commerciales ou types de données. Pour de plus amples informations sur les wrappers de données externes prises en charge par RDS for PostgreSQL, veuillez consulter Utilisation des encapsuleurs de données externes pris en charge pour Amazon RDS for PostgreSQL.

Ci-dessous, vous trouverez des informations sur certaines autres fonctionnalités prises en charge par RDS for PostgreSQL.

Types de données et énumérations personnalisés avec RDS for PostgreSQL

PostgreSQL prend en charge la création de types de données personnalisés et l'utilisation d'énumérations. Pour de plus amples informations sur la création et l'utilisation d'énumérations et d'autres types de données, veuillez consulter Types énumérés dans la documentation PostgreSQL.

Voici un exemple de création d'un type en tant qu'énumération, puis d'insertion de valeurs dans une table.

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)

Déclencheurs d'évènements pour RDS for PostgreSQL

Toutes les versions actuelles de PostgreSQL prennent en charge les déclencheurs d'événements, tout comme toutes les versions disponibles de RDS for PostgreSQL. Vous pouvez utiliser le compte d'utilisateur principal (par défaut, postgres) pour créer, modifier, renommer et supprimer des déclencheurs d'évènements. Les déclencheurs d'évènements sont au niveau de l'instance de base de données, de sorte qu'ils peuvent s'appliquer à toutes les bases de données sur une instance.

Par exemple, le code suivant crée un déclencheur d'évènement qui imprime l'utilisateur actuel à la fin de chaque commande DDL.

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

Pour plus d'informations sur les déclencheurs d'évènements PostgreSQL, consultez Déclencheurs d'évènements dans la documentation de PostgreSQL.

Il existe plusieurs restrictions quant à l'utilisation de déclencheurs d'évènements PostgreSQL sur Amazon RDS. Tel est le cas des éléments suivants :

  • Vous ne pouvez pas créer de déclencheurs d'évènements sur les réplicas en lecture. En revanche, vous pouvez créer de déclencheurs d'évènements sur une source de réplica en lecture. Les déclencheurs d'évènements sont ensuite copiés sur le réplica en lecture. Les déclencheurs d'évènements sur le réplica en lecture ne s'activent pas sur le réplica en lecture lorsque les modifications sont poussées depuis la source. En revanche, si le réplica en lecture est promu, les déclencheurs d'évènements existants s'activent lorsque des opérations de base de données ont lieu.

  • Pour effectuer une mise à niveau de version majeure vers une instance de base de données PostgreSQL qui utilise des déclencheurs d'évènements, vous devez supprimer les déclencheurs d'évènements avant de procéder à la mise à niveau de l'instance.

Grandes pages pour RDS for PostgreSQL

Les Huge pages (Grandes pages) sont une fonction de gestion de la mémoire qui réduit la surcharge lorsqu'une instance de base de données fonctionne avec de gros morceaux de mémoire contigus, tels que ceux utilisés par les tampons partagés. Cette fonction PostgreSQL est prise en charge par toutes les versions actuellement disponibles de RDS for PostgreSQL. Vous allouez de grandes pages pour votre application en utilisant des appels à la mémoire partagée mmap ou SYSV. RDS for PostgreSQL prend en charge les tailles de pages de 4 Ko et de 2 Mo.

Vous pouvez activer ou désactiver les Grandes pages en modifiant la valeur du paramètre huge_pages. La fonction est activée par défaut pour toutes les classes d'instances de base de données autres que les classes micro, petites et medium.

RDS for PostgreSQL utilise les grandes pages en fonction de la mémoire partagée disponible. Si l'instance de base de données ne peut pas utiliser les grandes pages en raison des contraintes de mémoire partagée, Amazon RDS empêche le démarrage de l'instance de base de données. Dans ce cas, Amazon RDS affecte au statut de l'instance de base de données un état indiquant l'incompatibilité des paramètres. Dans ce cas, vous pouvez affecter la valeur « huge_pages » au paramètre off pour autoriser Amazon RDS à démarrer l'instance de bases de données.

Le paramètre shared_buffers est essentiel pour définir le pool de mémoire partagée requis pour utiliser les grandes pages. La valeur par défaut du paramètre shared_buffers utilise une macro de paramètres de base de données. Cette macro définit un pourcentage du total des 8 Ko pages disponibles pour la mémoire de l'instance de base de données. Lorsque vous utilisez des grandes pages, celles-ci se trouvent avec les grandes pages. Amazon RDS affecte à une instance de base de données dans un état indiquant l'incompatibilité des paramètres si les paramètres de mémoire partagée définis requièrent plus de 90 % de la mémoire de l'instance de base de données.

Pour en savoir plus sur la gestion de la mémoire PostgreSQL, veuillez consulter Resource Consumption dans la documentation PostgreSQL.

Réplication logique pour Amazon RDS for PostgreSQL

Dès la version 10.4, RDS for PostgreSQL prend en charge la syntaxe SQL de publication et d'abonnement qui a été introduite dans PostgreSQL 10. Pour en savoir plus, veuillez consulter Réplication logique dans la documentation PostgreSQL.

Note

Outre la fonctionnalité de réplication logique native de PostgreSQL introduite dans PostgreSQL 10, RDS for PostgreSQL prend également en charge l'extension pglogical. Pour de plus amples informations, veuillez consulter Utilisation de pglogical pour synchroniser les données entre les instances.

Ci-dessous, vous trouverez des informations sur la configuration de la réplication logique pour une instance de base de données RDS for PostgreSQL.

Compréhension de la réplication logique et du décodage logique

RDS for PostgreSQL prend en charge le streaming des modifications WAL (write-ahead log) à l'aide d'emplacements de réplication logique PostgreSQL. Il prend également en charge l'utilisation du décodage logique. Vous pouvez configurer des emplacements logiques de réplication sur votre instance et diffuser les modifications de base de données à travers ces emplacements pour un client comme pg_recvlogical. Les emplacements logiques de réplication sont créés au niveau de la base de données et prennent en charge les connexions de réplication avec une base de données unique.

Les clients plus courants pour la réplication logique PostgreSQL sont AWS Database Migration Service ou un hôte géré de manière personnalisée sur une instance Amazon EC2. L'emplacement de réplication logique ne contient aucune information sur le récepteur du flux. De plus, il n'est pas nécessaire que la cible soit une base de données de réplica. Si vous configurez un emplacement de réplication logique et que vous ne lisez pas à partir de l'emplacement, les données peuvent être écrites dans le stockage de votre instance de base de données et le remplir rapidement.

La réplication logique et le décodage logique PostgreSQL sur Amazon RDS sont activés avec un paramètre, un type de connexion de réplication et un rôle de sécurité. Le client pour le décodage logique peut être n'importe quel client capable d'établir une connexion de réplication avec une base de données sur une instance de base de données PostgreSQL.

Pour activer le décodage logique pour une instance de base de données RDS for PostgreSQL
  1. Assurez-vous que le compte utilisateur que vous utilisez possède les rôles suivants :

    • Le rôle rds_superuser de manière à ce que vous puissiez activer la réplication logique

    • Le rôle rds_replication pour accorder les autorisations de gérer des emplacements logiques et de diffuser les données à l'aide d'emplacements logiques

  2. Définissez le paramètre statique rds.logical_replication sur 1. Dans le cadre de l'application de ce paramètre, configurez également les paramètres wal_level, max_wal_senders, max_replication_slots et max_connections. Ces modifications de paramètres peuvent accroître la génération WAL de sorte que vous ne devez définir le paramètre rds.logical_replication que lorsque vous utilisez des emplacements logiques.

  3. Redémarrez l'instance de base de données pour que le paramètre statique rds.logical_replication prenne effet.

  4. Créez un emplacement de réplication logique comme expliqué dans la section suivante. Cela nécessite que vous précisiez un plugin de décodage. Actuellement, RDS for PostgreSQL prend en charge les plugins de sortie test_decoding et wal2json fournis avec PostgreSQL.

Pour plus d'informations sur le décodage logique PostgreSQL, consultez la documentation PostgreSQL.

Utilisation des emplacements de réplication logique

Vous pouvez utiliser les commandes SQL pour utiliser les emplacements logiques. Par exemple, la commande suivante crée un emplacement logique nommé test_slot à l'aide du plugin de sortie PostgreSQL par défaut test_decoding.

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

Pour lister les emplacements logiques, utilisez la commande suivante.

SELECT * FROM pg_replication_slots;

Pour supprimer un emplacement logique, utilisez la commande suivante.

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

Pour plus d'exemples sur l'utilisation des emplacements de réplication logique, consultez Exemples de décodage logique dans la documentation PostgreSQL.

Après avoir créé l'emplacement de réplication logique, vous pouvez commencer le streaming. L'exemple suivant montre comment le décodage logique est contrôlé par le protocole de streaming. Celui-ci utilise le programme pg_recvlogical, qui est inclus dans la distribution PostgreSQL. Cela nécessite que l'authentification du client soit configurée pour autoriser les connexions de réplication.

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

Pour afficher le contenu de la vue pg_replication_origin_status, interrogez la fonction pg_show_replication_origin_status.

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

Disque RAM pour le stats_temp_directory

Vous pouvez utiliser le paramètre RDS for PostgreSQL rds.pg_stat_ramdisk_size pour spécifier la mémoire système allouée à un disque RAM afin de stocker le code PostgreSQL stats_temp_directory. Le paramètre de disque RAM est disponible pour toutes les versions de PostgreSQL sur Amazon RDS.

Avec certaines charges de travail, ce paramètre peut améliorer les performances et réduire les exigences relatives aux I/O. Pour plus d'informations sur le paramètre stats_temp_directory, veuillez consulter la documentation sur PostgreSQL.

Pour activer un disque RAM pour votre stats_temp_directory, définissez le paramètre rds.pg_stat_ramdisk_size sur une valeur littérale entière dans le groupe de paramètres utilisé par votre instance de base de données. Ce paramètre est indiqué en Mo, vous devez donc utiliser une valeur entière. Les expressions, formules et fonctions ne sont pas valides pour le paramètre rds.pg_stat_ramdisk_size. Veillez à réinitialiser l'instance de base de données pour que la modification prenne effet. Pour plus d'informations sur la définition des paramètres, consultez Utilisation des groupes de paramètres.

Par exemple, la commande d'AWS CLI suivante définit le paramètre de disque RAM à 256 Mo.

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"

Après le redémarrage, exécutez la commande suivante pour afficher le statut de stats_temp_directory.

postgres=> SHOW stats_temp_directory;

La commande devrait renvoyer le résultat suivant.

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

Espaces de table pour RDS for PostgreSQL

RDS for PostgreSQL prend en charge les espaces de table à des fins de compatibilité. Étant donné que tout le stockage se trouve sur un seul volume logique, vous ne pouvez pas utiliser d'espaces de table pour le fractionnement ou l'isolement des I/O. Nos évaluations et notre expérience indiquent qu'un seul volume logique constitue la meilleure configuration dans la plupart des cas d'utilisation.

Pour créer et utiliser des espaces de table avec votre instance de base de données RDS for PostgreSQL, vous avez besoin du rôle rds_superuser. Le compte utilisateur principal de votre instance de base de données RDS for PostgreSQL (par défaut, postgres) est membre de ce rôle. Pour de plus amples informations, veuillez consulter Comprendre les rôles et les autorisations PostgreSQL.

Si vous spécifiez un nom de fichier lors de la création d'un espace de table, le préfixe du chemin est /rdsdbdata/db/base/tablespace. L'exemple suivant montre comment placer les fichiers d'espace de table dans /rdsdbdata/db/base/tablespace/data. Cet exemple suppose qu'un utilisateur dbadmin (rôle) existe et qu'il se soit vu accorder le rôle rds_superuser nécessaire à l'utilisateur des espaces de table.

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

Pour en savoir plus sur les espaces de table PostgreSQL, veuillez consulter Tablespaces dans la documentation PostgreSQL.

Classements RDS pour PostgreSQL pour EBCDIC et autres migrations mainframe.

Les versions 10 et ultérieures de RDS pour PostgreSQL comprennent la version 60.2 d'ICU, qui est basée sur Unicode 10.0 et inclut les classements du référentiel de données localisées commun d'Unicode, CLDR 32. Ces bibliothèques d'internationalisation logicielle garantissent que les codages de caractères sont présentés de manière cohérente, quel que soit le système d'exploitation ou la plateforme. Pour obtenir plus d'informations sur le CLDR-32 d'Unicode, consultez la section CLDR 32 Release Note (Note de mise à jour du CLDR 32) sur le site Web du CLDR d'Unicode. Vous pouvez en savoir plus sur les composants d'internationalisation pour Unicode (ICU) sur le site Web du comité technique ICU (ICU-TC). Pour plus d'informations sur ICU-60, consultez la section Download ICU 60 (Télécharger ICU 60).

À partir de la version 14.3, RDS pour PostgreSQL inclut également des classements qui facilitent l'intégration des données et la conversion des systèmes basés sur EBCDIC. Le code d'échange décimal codé binaire étendu ou EBCDIC est couramment utilisé par les systèmes d'exploitation mainframe. Ces classements fournis par Amazon RDS sont étroitement définis pour trier uniquement les caractères Unicode qui correspondent directement aux pages de code EBCDIC. Les caractères sont triés dans l'ordre des points de code EBCDIC pour permettre la validation des données après la conversion. Ces classements ne comprennent pas les formes dénormalisées, ni les caractères Unicode qui ne correspondent pas directement à un caractère de la page de code EBCDIC source.

Les mappages de caractères entre les pages de code EBCDIC et les points de code Unicode sont basées sur les tables publiées par IBM. Le jeu complet est disponible auprès d'IBM sous forme de fichier compressé à télécharger. RDS for PostgreSQL a utilisé ces mappages avec les outils fournis par l'ICU pour créer les classements listés dans les tableaux de cette section. Les noms de classement comprennent une langue et un pays, comme l'exige l'ICU. Cependant, les pages de codes EBCDIC ne précisent pas les langues, et certaines pages de codes EBCDIC couvrent plusieurs pays. Cela signifie que les parties langue et pays des noms de classement dans la table sont arbitraires et qu'elles ne doivent pas nécessairement correspondre à la locale actuelle. En d'autres termes, le numéro de page de code est la partie la plus importante du nom du classement dans ce tableau. Vous pouvez utiliser tous les classements répertoriés dans les tableaux suivants dans n'importe quelle base de données RDS pour PostgreSQL.

  • Unicode to EBCDIC collations table : certains outils de migration de données mainframe utilisent en interne LATIN1 ou LATIN9 pour encoder et traiter les données. Ces outils utilisent des schémas aller-retour pour préserver l'intégrité des données et prendre en charge la conversion inverse. Les classements de ce tableau peuvent être utilisés par des outils qui traitent les données en utilisant l'encodage LATIN1, qui ne nécessite pas de traitement particulier.

  • Unicode to LATIN9 collations table : vous pouvez utiliser ces classements dans n'importe quelle base de données RDS for PostgreSQL.

Dans le tableau suivant, vous trouverez les classements disponibles dans RDS pour PostgreSQL qui font correspondre les pages de code EBCDIC aux points de code Unicode. Nous vous recommandons d'utiliser les classements de ce tableau pour le développement d'applications qui nécessitent un classement basé sur l'ordre des pages de code IBM.

Nom du classement PostgreSQL Description du mappage code-page et de l'ordre de tri

da-DK-cp277-x-icu

Les caractères Unicode qui mappent directement à la page de code EBCDIC 277 d'IBM (selon les tables de conversion) sont triés dans l'ordre des points de code CP 277 d'IBM.

de-DE-cp273-x-icu

Les caractères Unicode qui mappent directement à la page de code EBCDIC 273 d'IBM (selon les tables de conversion) sont triés dans l'ordre des points de code CP 273 d'IBM.

en-GB-cp285-x-icu

Les caractères Unicode qui mappent directement à la page de code EBCDIC 285 d'IBM (selon les tables de conversion) sont triés dans l'ordre des points de code CP 285 d'IBM.

en-US-cp037-x-icu

Les caractères Unicode qui mappent directement à la page de code EBCDIC 037 d'IBM (selon les tables de conversion) sont triés dans l'ordre des points de code CP 37 d'IBM.

es-ES-cp284-x-icu

Les caractères Unicode qui mappent directement à la page de code EBCDIC 284 d'IBM (selon les tables de conversion) sont triés dans l'ordre des points de code CP 284 d'IBM.

fi-FI-cp278-x-icu

Les caractères Unicode qui mappent directement à la page de code EBCDIC 278 d'IBM (selon les tables de conversion) sont triés dans l'ordre des points de code CP 278 d'IBM.

fr-FR-cp297-x-icu

Les caractères Unicode qui mappent directement à la page de code EBCDIC 297 d'IBM (selon les tables de conversion) sont triés dans l'ordre des points de code CP 297 d'IBM.

it-IT-cp280-x-icu

Les caractères Unicode qui mappent directement à la page de code EBCDIC 280 d'IBM (selon les tables de conversion) sont triés dans l'ordre des points de code CP 280 d'IBM.

nl-BE-cp500-x-icu

Les caractères Unicode qui mappent directement à la page de code EBCDIC 500 d'IBM (selon les tables de conversion) sont triés dans l'ordre des points de code CP 500 d'IBM.

Amazon RDS fournit un ensemble de classements supplémentaires qui trient les points de code Unicode qui correspondent aux caractères LATIN9 en utilisant les tables publiées par IBM, dans l'ordre des points de code d'origine selon la page de code EBCDIC des données sources.

Nom du classement PostgreSQL Description du mappage code-page et de l'ordre de tri

da-DK-cp1142m-x-icu

Les caractères Unicode qui correspondent aux caractères LATIN9 convertis à l'origine à partir de la page de code IBM EBCDIC 1142 (selon les tables de conversion) sont triés dans l'ordre des points de code IBM CP 1142.

de-DE-cp1141m-x-icu

Les caractères Unicode qui correspondent aux caractères LATIN9 convertis à l'origine à partir de la page de code IBM EBCDIC 1141 (selon les tables de conversion) sont triés dans l'ordre des points de code IBM CP 1141.

en-GB-cp1146m-x-icu

Les caractères Unicode qui correspondent aux caractères LATIN9 convertis à l'origine à partir de la page de code IBM EBCDIC 1146 (selon les tables de conversion) sont triés dans l'ordre des points de code IBM CP 1146.

en-US-cp1140m-x-icu

Les caractères Unicode qui correspondent aux caractères LATIN9 convertis à l'origine à partir de la page de code IBM EBCDIC 1140 (selon les tables de conversion) sont triés dans l'ordre des points de code IBM CP 1140.

es-ES-cp1145m-x-icu

Les caractères Unicode qui correspondent aux caractères LATIN9 convertis à l'origine à partir de la page de code IBM EBCDIC 1145 (selon les tables de conversion) sont triés dans l'ordre des points de code IBM CP 1145.

fi-FI-cp1143m-x-icu

Les caractères Unicode qui correspondent aux caractères LATIN9 convertis à l'origine à partir de la page de code IBM EBCDIC 1143 (selon les tables de conversion) sont triés dans l'ordre des points de code IBM CP 1143.

fr-FR-cp1147m-x-icu

Les caractères Unicode qui correspondent aux caractères LATIN9 convertis à l'origine à partir de la page de code IBM EBCDIC 1147 (selon les tables de conversion) sont triés dans l'ordre des points de code IBM CP 1147.

it-IT-cp1144m-x-icu

Les caractères Unicode qui correspondent aux caractères LATIN9 convertis à l'origine à partir de la page de code IBM EBCDIC 1144 (selon les tables de conversion) sont triés dans l'ordre des points de code IBM CP 1144.

nl-BE-cp1148m-x-icu

Les caractères Unicode qui correspondent aux caractères LATIN9 convertis à l'origine à partir de la page de code IBM EBCDIC 1148 (selon les tables de conversion) sont triés dans l'ordre des points de code IBM CP 1148.

Dans ce qui suit, vous trouverez un exemple d'utilisation d'un classement RDS pour 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

Nous vous recommandons d'utiliser les classements dans le Unicode to EBCDIC collations table et Unicode to LATIN9 collations table pour le développement d'applications qui nécessitent un classement basé sur l'ordre des pages de code IBM. Les classements suivants (suffixés par la lettre « b ») sont également visibles en pg_collation, mais sont destinés à être utilisés par des outils d'intégration et de migration de données mainframe sur AWS qui mappent les pages de code avec des décalages de points de code spécifiques et nécessitent un traitement spécial dans le classement. En d'autres termes, l'utilisation des classements suivants n'est pas recommandée.

  • 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

Pour en savoir plus sur la migration des applications d'un environnement mainframe vers AWS, consultez Qu'est-ce qu'AWS Mainframe Modernization ?.

Pour obtenir plus d'informations sur la gestion des classements dans PostgreSQL, consultez la section Collation Support (Prise en charge des classements) dans la documentation de PostgreSQL.