PostgreSQL propose deux types de stockage des données JSON: json
et jsonb
. Pour implémenter des mécanismes de requête efficaces pour ces types de données, PostgreSQL fournit également le type de données jsonpath décrit dans la Section 8.14.6 .
Les types de données json
et jsonb
acceptent des ensembles de valeurs presque identiques en entrée. La principale différence pratique est celle de l'efficacité. Le
json
type de données stocke une copie exacte du texte d'entrée, que les fonctions de traitement doivent réanalyser à chaque exécution; tandis que les jsonb
données sont stockées dans un format binaire décomposé qui le rend légèrement plus lent à entrer en raison de la surcharge de conversion ajoutée, mais beaucoup plus rapide à traiter, car aucune nouvelle analyse n'est nécessaire. jsonb
prend également en charge l'indexation, ce qui peut être un avantage significatif.
Étant donné que le json
type stocke une copie exacte du texte d'entrée, il préservera l'espace blanc sémantiquement insignifiant entre les jetons, ainsi que l'ordre des clés dans les objets JSON. De plus, si un objet JSON dans la valeur contient plusieurs fois la même clé, toutes les paires clé / valeur sont conservées. (Les fonctions de traitement considèrent la dernière valeur comme opérationnelle.) En revanche, jsonb
ne conserve pas d'espace blanc, ne préserve pas l'ordre des clés d'objet et ne conserve pas les clés d'objet en double. Si des clés en double sont spécifiées dans l'entrée, seule la dernière valeur est conservée.
En général, la plupart des applications devraient préférer stocker les données JSON sous la forme
jsonb
, sauf s'il existe des besoins assez spécialisés, tels que des hypothèses héritées sur l'ordre des clés d'objet.
PostgreSQL autorise un seul codage de jeu de caractères par base de données. Il n'est donc pas possible pour les types JSON de se conformer de manière rigide à la spécification JSON à moins que le codage de la base de données soit UTF8. Les tentatives visant à inclure directement des caractères qui ne peuvent pas être représentés dans le codage de la base de données échoueront; à l'inverse, les caractères qui peuvent être représentés dans l'encodage de la base de données mais pas en UTF8 seront autorisés.