Documentation PostgreSQL 15.15 » Internes » Définition de l'interface des méthodes d'accès aux tables

Précédent | Niveau supérieur | Suivant
62.4. Lectures supplémentaires | Sommaire | Chapitre 64. Définition de l'interface des méthodes d'accès aux index

## Chapitre 63. Définition de l'interface des méthodes d'accès aux tables

Ce chapitre explique l'interface entre le système PostgreSQL et les méthodes d'accès aux tables, qui gèrent le stockage des tables. Le cœur du système connaît très peu de choses sur ces méthodes d'accès en dehors de ce qui est spécifié ici, donc il est possible de développer de nouvelles méthodes d'accès en écrivant un code supplémentaire.

Chaque méthode d'accès aux tables est décrite par une ligne dans le catalogue système `pg_am`. L'enregistrement dans `pg_am` précise un nom et une fonction de gestion pour la méthode d'accès à la table. Ces enregistrements peuvent être créés et supprimés en utilisant les commandes SQL CREATE ACCESS METHOD et DROP ACCESS METHOD.

Une fonction de gestion de la méthode d'accès aux tables doit être déclarée comme acceptant un seul argument de type `internal` et doit renvoyer le pseudo-type `table_am_handler`. L'argument est une valeur bateau qui sert simplement à empêcher l'appel de fonctions de gestion à partir de simples commandes SQL. Le résultat de la fonction doit être un pointeur vers une structure de type `TableAmRoutine`, qui contient tout ce que le cœur du moteur a besoin de savoir pour utiliser la méthode d'accès aux tables. La valeur de retour doit avoir une durée de vie valable pour toute la durée d'exécution du serveur, ce qui se fait habituellement en la définissant comme une variable de type `static const` de façon globale. La structure `TableAmRoutine`, aussi appelée structure API de la méthode d'accès, définit le comportement de la méthode d'accès en utilisant des callbacks. Ces callbacks sont des pointeurs vers des fonctions C et ne sont pas visibles ou appelables au niveau du langage SQL. Tous les callbacks et leurs comportements sont définis dans la structure `TableAmRoutine` (avec des commentaires dans le structure définissant les prérequis des callbacks). La plupart des callbacks ont des fonctions wrapper, documentées du point de vue de l'utilisateur (plutôt que de l'implémenteur) de la méthode d'accès aux tables. Pour les détails, voir le fichier `src/include/access/tableam.h`.

Pour implémenter une méthode d'accès, un implémenteur aura habituellement besoin d'implémenter un type spécifique AM de ligne (voir `src/include/executor/tuptable.h`), qui permet à du code en dehors de la méthode d'accès de détenir des références sur les lignes de l'AM, et d'accéder aux colonnes de la ligne.

Actuellement, la façon dont un AM enregisrre les données est très peu contrainte. Par exemple, il est possible, mais non requis, d'utiliser le cache disque de PostgreSQL. Au cas où il est utilisé, il est sensé d'utiliser la disposition standard d'une page de PostgreSQL comme décrit dans Section 73.6.

Une importante contrainte de l'API de méthode d'accès aux tables est qu'actuellement, si l'AM veut accepter les modifications et/ou les index, il est nécessaire que chaque ligne ait un identifiant de ligne (TID) consistant en un numéro de bloc et un numéro d'enregistrement (voir aussi Section 73.6). IL n'est pas strictement nécessaire que les sous-parties des TIDs aient cette même signification, avoir un `heap`, mais si le support de parcours de bitmap est souhaité (c'est optionnel), le numéro de bloc doit fournir une localisation.

Pour la sécurité des données, un AM doit utiliser les WAL de PostgreSQL ou une implémentation personnalisée. Si les WAL sont choisis, des enregistrements génériques des WAL peuvent être utilisés. Vous pouvez aussi implémenter un nouveau type d'enregistrements WAL (voir Gestionnaire personnalisé de ressources WAL).

Pour implémenter le support transactionnel d'une façon qui permet à différentes méthodes d'accès aux tables d'être accédées dans une seule transaction, il est généralement nécessaire d'intégrer ce qui se trouve dans `src/backend/access/transam/xlog.c`.

Tout développeur d'une nouvelle `méthode d'accès aux tables` peut se référer à l'implémentation existante de `heap` dans `src/backend/access/heap/heapam_handler.c` pour les détails de son implémentation.