10.1. Vue d'ensemble

SQL est un langage fortement typé. C'est-à-dire que chaque élément de données est associé à un type de données qui détermine son comportement et son utilisation permise. PostgreSQL a un système de types extensible qui est beaucoup plus général et flexible que les autres implémentations de SQL. Par conséquent, la plupart des comportements de conversion de types dans PostgreSQL est régie par des règles générales plutôt que par une heuristique ad hoc. Cela permet aux expressions de types mixtes d'être significatives même avec des types définis par l'utilisateur.

L'analyseur de PostgreSQL divise les éléments lexicaux en seulement cinq catégories fondamentales : les entiers, les nombres non entiers, les chaînes de caractères, les identifieurs et les mots-clé. Les constantes de la plupart des types non-numériques sont d'abord classifiées comme chaînes de caractères. La définition du langage SQL permet de spécifier le nom des types avec une chaîne et ce mécanisme peut être utilisé dans PostgreSQL pour lancer l'analyseur sur le bon chemin. Par exemple, la requête

SELECT text 'Origin' AS "label", point '(0,0)' AS "value";

 label  | value
--------+-------
 Origin | (0,0)
(1 row)

a deux constantes littérales, de type text et point. Si un type n'est pas spécifié pour une chaîne littérale, alors le type inconnu est assigné initialement pour être résolu dans les étapes ultérieures comme décrit plus bas.

Il y a quatre constructions SQL fondamentales qui exigent des règles distinctes de conversion de types dans l'analyseur de PostgreSQL :

Les catalogues systèmes stockent les informations au sujet de la validité des conversions entre les types de données et comment exécuter ces conversions. Les conversions sont appelées casts en anglais. Des conversions de types supplémentaires peuvent être ajoutées par l'utilisateur avec la commande CREATE CAST. (Cela est habituellement fait en conjonction avec la définition de nouveaux types de données. L'ensemble des conversions entre les types prédéfinis a été soigneusement choisi et le mieux est de ne pas le modifier.)

Concernant les types SQL standards, une heuristique additionnelle est fournie dans l'analyseur pour permettre de meilleures estimations du comportement approprié. Il y a plusieurs catégories de types basiques définies : boolean, numeric, string, bitstring, datetime, timespan, geometric, network et utilisateurs. Chaque catégorie, à l'exception des types définis par l'utilisateur, a un ou plusieurs types pré-définis qui sont préférentiellement choisis quand il y a une ambiguïté. Dans la catégorie des types utilisateurs, chaque type est son propre type préféré. Les expressions ambiguës (celles avec de multiples solutions d'analyse candidates) peuvent souvent être résolues quand il y a de nombreux types pré-définis possibles mais elles soulèveront une erreur quand il existe des choix multiples pour des types utilisateurs.

Toutes les règles de conversions de types sont écrites en gardant à l'esprit plusieurs principes :

• Les conversions implicites ne doivent jamais avoir de résultats surprenants ou imprévisibles.

• Les types utilisateurs dont l'analyseur n'a pas à priori connaissance, devraient être << plus hauts >> dans la hiérarchie des types. Dans les expressions de types mixtes, les types natifs doivent toujours être convertis en un type utilisateur (seulement si la conversion est nécessaire bien sûr).

• Les types utilisateurs ne sont pas reliés. Actuellement PostgreSQL n'a pas d'informations disponibles sur les relations entre les types, autres que celles fournies par les heuristiques codées en dur pour les types natifs et les relations implicites basées sur les fonctions et les conversions disponibles.

• Il n'y aura pas de surcharge depuis l'analyseur ou l'exécuteur si une requête n'a pas besoin d'une conversion de types implicite. C'est-à-dire que si une requête est bien formulée et si les types sont déjà assortis, alors la requête devra s'exécuter sans perte de temps supplémentaire et sans introduire à l'intérieur de celle-ci des appels à des conversions implicites non nécessaires.

  De plus, si une requête nécessite habituellement une conversion implicite pour une fonction et si l'utilisateur définit une nouvelle fonction avec les types des arguments corrects, l'analyseur devrait utiliser cette nouvelle fonction et ne fera plus des conversions implicites en utilisant l'ancienne fonction.