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 de ligne spécifique à une AM (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 65.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 65.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.