| Documentation PostgreSQL 8.0.25 | ||||
|---|---|---|---|---|
| Pr�c�dent | Arri�re rapide | Avance rapide | Suivant | |
Le m�lange de diff�rents types de donn�es dans la m�me expression peut �tre requis, intentionnellement ou pas, par les instructions SQL. PostgreSQL poss�de des fonctionnalit�s �tendues pour �valuer les expressions de type mixte.
Dans la plupart des cas, un utilisateur n'aura pas besoin de comprendre les d�tails du m�canisme de conversion des types. Cependant, les conversions implicites faites par PostgreSQL peuvent affecter le r�sultat d'une requ�te. Quand cela est n�cessaire, ces r�sultats peuvent �tre atteints directement en utilisant la conversion explicite de types.
Ce chapitre introduit les m�canismes et les conventions sur les conversions de types dans PostgreSQL. R�f�rez-vous aux sections appropri�es du Chapitre 8 et du Chapitre 9 pour plus d'informations sur les types de donn�es sp�cifiques, les fonctions et les op�rateurs autoris�s.
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 :
Une grande partie du syst�me de types de PostgreSQL est construit autour d'un riche ensemble de fonctions. Les fonctions peuvent avoir un ou plusieurs arguments. Puisque que PostgreSQL permet la surcharge des fonctions, le nom seul de la fonction n'identifie pas de mani�re unique la fonction � appeler ; l'analyseur doit s�lectionner la bonne fonction par rapport aux types des arguments fournis.
PostgreSQL autorise les expressions avec des op�rateurs de pr�fixe et de suffixe unaires (un argument) aussi bien que binaires (deux arguments). Comme les fonctions, les op�rateurs peuvent �tre surcharg�s, et donc le m�me probl�me existe pour s�lectionner le bon op�rateur.
Les clauses SQL INSERT et UPDATE placent le r�sultat des expressions dans une table. Les expressions dans une clause doivent �tre en accord avec le type des colonnes cibles et peuvent �tre converties vers celles-ci.
Comme toutes les requ�tes issues d'une clause SELECT utilisant une union doivent appara�tre dans un ensemble unique de colonnes, les types de r�sultats de chaque clause SELECT doivent �tre assortis et convertis en un ensemble uniforme. De fa�on similaire, les expressions de r�sultats d'une construction CASE doivent �tre converties vers un type commun de fa�on � ce que l'ensemble de l'expression CASE ait un type de sortie connu. Cela est la m�me chose pour les constructions avec ARRAY.
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.
| Pr�c�dent | Sommaire | Suivant |
| Fonctions d'administration syst�me | Niveau sup�rieur | Op�rateurs |