Tous ces champs sont disponibles dans le module django.contrib.postgres.fields.
Que ce soit avec Index ou Field.db_index, c’est un index B-tree qui est créé, ce qui n’est pas spécialement utile lors de requêtes sur des types de données complexes. Les index tels que GinIndex et GistIndex sont mieux adaptés, même si le choix de l’index dépend des requêtes effectivement utilisées. En général, GiST est un bon choix pour les champs d’intervalle et le champ HStoreField, alors que GIN est souvent utile pour les champs ArrayField et JSONField.
ArrayFieldLien vers cette rubrique#Un champ pour stocker des listes de données. La plupart des types de champs peuvent être utilisés ; passez une autre instance de champ dans l’attribut base_field. Vous pouvez aussi indiquer une taille dans size. ArrayField peut être imbriqué pour stocker des tableaux multidimensionnels.
Si vous donnez une valeur default à ce champ, assurez-vous que ce soit un objet exécutable tel que list (pour une valeur par défaut vide) ou un objet exécutable qui renvoie une liste (par exemple une fonction). L’utilisation de default=[] n’est pas correct car cela crée une valeur par défaut mutante qui est partagée entre les instances de ArrayField.
Ce paramètre est obligatoire.
\nDéfinit le type de données sous-jacent et le comportement du tableau. Il devrait s’agir d’une instance d’une sous-classe de Field. Par exemple, cela pourrait être un IntegerField ou un CharField. La plupart des types de champs sont autorisés, à l’exception de ceux qui gèrent des données relationnelles (ForeignKey, OneToOneField et ManyToManyField) et des champs fichiers (FileField et ImageField).
Il est possible d’imbriquer des champs tabulaires, c’est-à-dire que base_field peut contenir une instance de ArrayField. Par exemple :
from django.contrib.postgres.fields import ArrayField\nfrom django.db import models\n\n\nclass ChessBoard(models.Model):\n board = ArrayField(\n ArrayField(\n models.CharField(max_length=10, blank=True),\n size=8,\n ),\n size=8,\n )\nLa transformation de valeurs entre la base de données et le modèle, la validation de données et la configuration ainsi que la sérialisation sont tous délégués au champ de base sous-jacent.
\nCe paramètre est facultatif.
\nSi présent, le tableau aura la taille maximale indiquée. Cette valeur est transmise à la base de données, même si PostgreSQL n’applique actuellement pas cette restriction.
\nArrayFieldLien vers cette rubrique#Il existe plusieurs recherches et transformations spécifiques au champ ArrayField. Nous allons utiliser le modèle d’exemple suivant :
from django.contrib.postgres.fields import ArrayField\nfrom django.db import models\n\n\nclass Post(models.Model):\n name = models.CharField(max_length=200)\n tags = ArrayField(models.CharField(max_length=200), blank=True)\n\n def __str__(self):\n return self.name\ncontainsLien vers cette rubrique#La recherche contains est surchargée pour ArrayField. Les objets renvoyés sont ceux pour qui les valeurs transmises forment un sous-ensemble des données. Elle utilise l’opérateur SQL @>. Par exemple :
>>> Post.objects.create(name="First post", tags=["thoughts", "django"])\n>>> Post.objects.create(name="Second post", tags=["thoughts"])\n>>> Post.objects.create(name="Third post", tags=["tutorial", "django"])\n\n>>> Post.objects.filter(tags__contains=["thoughts"])\n<QuerySet [<Post: First post>, <Post: Second post>]>\n\n>>> Post.objects.filter(tags__contains=["django"])\n<QuerySet [<Post: First post>, <Post: Third post>]>\n\n>>> Post.objects.filter(tags__contains=["django", "thoughts"])\n<QuerySet [<Post: First post>]>\ncontained_byLien vers cette rubrique#Il s’agit de l’inverse de la recherche contains, les objets renvoyés sont ceux pour qui les données forment un sous-ensemble des valeurs transmises. Elle utilise l’opérateur SQL <@. Par exemple :
>>> Post.objects.create(name="First post", tags=["thoughts", "django"])\n>>> Post.objects.create(name="Second post", tags=["thoughts"])\n>>> Post.objects.create(name="Third post", tags=["tutorial", "django"])\n\n>>> Post.objects.filter(tags__contained_by=["thoughts", "django"])\n<QuerySet [<Post: First post>, <Post: Second post>]>\n\n>>> Post.objects.filter(tags__contained_by=["thoughts", "django", "tutorial"])\n<QuerySet [<Post: First post>, <Post: Second post>, <Post: Third post>]>\noverlapLien vers cette rubrique#Renvoie les objets dont les données contiennent au moins une valeur en commun avec celles transmises. Utilise l’opérateur SQL &&. Par exemple :
>>> Post.objects.create(name="First post", tags=["thoughts", "django"])\n>>> Post.objects.create(name="Second post", tags=["thoughts", "tutorial"])\n>>> Post.objects.create(name="Third post", tags=["tutorial", "django"])\n\n>>> Post.objects.filter(tags__overlap=["thoughts"])\n<QuerySet [<Post: First post>, <Post: Second post>]>\n\n>>> Post.objects.filter(tags__overlap=["thoughts", "tutorial"])\n<QuerySet [<Post: First post>, <Post: Second post>, <Post: Third post>]>\n\n>>> Post.objects.filter(tags__overlap=Post.objects.values_list("tags"))\n<QuerySet [<Post: First post>, <Post: Second post>, <Post: Third post>]>\nlenLien vers cette rubrique#Renvoie la longueur du tableau. Les recherches disponibles à la suite de celle-ci sont celles qui sont disponibles pour les champs IntegerField. Par exemple :
>>> Post.objects.create(name="First post", tags=["thoughts", "django"])\n>>> Post.objects.create(name="Second post", tags=["thoughts"])\n\n>>> Post.objects.filter(tags__len=1)\n<QuerySet [<Post: Second post>]>\nLes transformations d’index indicent dans les tableaux. Tout nombre entier non négatif est utilisable. Aucune erreur n’est produite si l’indice dépasse la taille size du tableau. Les recherches disponibles à la suite de la transformation sont celles du champ base_field. Par exemple :
>>> Post.objects.create(name="First post", tags=["thoughts", "django"])\n>>> Post.objects.create(name="Second post", tags=["thoughts"])\n\n>>> Post.objects.filter(tags__0="thoughts")\n<QuerySet [<Post: First post>, <Post: Second post>]>\n\n>>> Post.objects.filter(tags__1__iexact="Django")\n<QuerySet [<Post: First post>]>\n\n>>> Post.objects.filter(tags__276="javascript")\n<QuerySet []>\nLes transformations de segmentation segmentent dans les tableaux. Toute paire de nombres entiers non négatifs peut être utilisée, séparée par un seul soulignement. Les recherches disponibles après la transformation ne changent pas. Par exemple :
\n>>> Post.objects.create(name="First post", tags=["thoughts", "django"])\n>>> Post.objects.create(name="Second post", tags=["thoughts"])\n>>> Post.objects.create(name="Third post", tags=["django", "python", "thoughts"])\n\n>>> Post.objects.filter(tags__0_1=["thoughts"])\n<QuerySet [<Post: First post>, <Post: Second post>]>\n\n>>> Post.objects.filter(tags__0_2__contains=["thoughts"])\n<QuerySet [<Post: First post>, <Post: Second post>]>\nCITextLien vers cette rubrique#Une classe mixin pour créer des champs texte insensibles à la casse soutenus par le type citext. Lisez les conséquences au niveau des performances avant de l’utiliser.
\nPour utiliser citext, employez l’opération CITextExtension afin de configurer l’extension citext dans PostgreSQL avant la première opération de migration CreateModel.
Si vous utilisez un champ ArrayField de CIText, vous devez ajouter 'django.contrib.postgres' dans votre réglage INSTALLED_APPS, sinon les valeurs de champs apparaîtront sous forme de chaînes comme '{thoughts,django}'.
Plusieurs champs qui utilisent cette classe mixin sont fournis :
\nCes champs héritent respectivement de CharField, EmailField et TextField.
max_length ne sera pas vérifiée au niveau de la base de données car citext se comporte comme le type PostgreSQL text.
HStoreFieldLien vers cette rubrique#Un champ pour stocker des paires clé-valeur. Le type de données Python utilisé est un dictionnaire dict. Les clés doivent être des chaînes et les valeurs peuvent être soit des chaînes, soit la valeur nulle (None en Python).
Pour utiliser ce champ, il faut :
\nAjouter 'django.contrib.postgres' à votre réglage INSTALLED_APPS.
Configurer l’extension hstore dans PostgreSQL.
Vous verrez une erreur du genre can't adapt type 'dict' si vous omettez la première étape, ou type "hstore" does not exist si vous omettez la seconde.
HStoreFieldLien vers cette rubrique#En plus de la possibilité d’interroger en fonction de la clé, il existe quelques recherches tout exprès pour les champs HStoreField.
Nous allons utiliser le modèle d’exemple suivant :
\nfrom django.contrib.postgres.fields import HStoreField\nfrom django.db import models\n\n\nclass Dog(models.Model):\n name = models.CharField(max_length=200)\n data = HStoreField()\n\n def __str__(self):\n return self.name\nPour rechercher en fonction d’une clé donnée, utilisez cette clé comme nom de requête :
\n>>> Dog.objects.create(name="Rufus", data={"breed": "labrador"})\n>>> Dog.objects.create(name="Meg", data={"breed": "collie"})\n\n>>> Dog.objects.filter(data__breed="collie")\n<QuerySet [<Dog: Meg>]>\nIl est possible d’enchaîner d’autres recherches après une recherche par clé :
\n>>> Dog.objects.filter(data__breed__contains="l")\n<QuerySet [<Dog: Rufus>, <Dog: Meg>]>\nou utilisez des expressions F() pour annoter une valeur de clé. Par exemple :
>>> from django.db.models import F\n>>> rufus = Dog.objects.annotate(breed=F("data__breed"))[0]\n>>> rufus.breed\n'labrador'\nSi la clé avec laquelle vous souhaitez rechercher entre en conflit avec le nom d’une recherche existante, vous devez utiliser la recherche hstorefield.contains à la place.
containsLien vers cette rubrique#La recherche contains est surchargée pour HStoreField. Les objets renvoyés sont ceux pour qui le dictionnaire de paires clé-valeur est totalement contenu dans le champ. Elle utilise l’opérateur SQL @>. Par exemple :
>>> Dog.objects.create(name="Rufus", data={"breed": "labrador", "owner": "Bob"})\n>>> Dog.objects.create(name="Meg", data={"breed": "collie", "owner": "Bob"})\n>>> Dog.objects.create(name="Fred", data={})\n\n>>> Dog.objects.filter(data__contains={"owner": "Bob"})\n<QuerySet [<Dog: Rufus>, <Dog: Meg>]>\n\n>>> Dog.objects.filter(data__contains={"breed": "collie"})\n<QuerySet [<Dog: Meg>]>\ncontained_byLien vers cette rubrique#Il s’agit de l’inverse de la recherche contains, les objets renvoyés sont ceux pour qui les paires de clé-valeur forment un sous-ensemble des valeurs transmises. Elle utilise l’opérateur SQL <@. Par exemple :
>>> Dog.objects.create(name="Rufus", data={"breed": "labrador", "owner": "Bob"})\n>>> Dog.objects.create(name="Meg", data={"breed": "collie", "owner": "Bob"})\n>>> Dog.objects.create(name="Fred", data={})\n\n>>> Dog.objects.filter(data__contained_by={"breed": "collie", "owner": "Bob"})\n<QuerySet [<Dog: Meg>, <Dog: Fred>]>\n\n>>> Dog.objects.filter(data__contained_by={"breed": "collie"})\n<QuerySet [<Dog: Fred>]>\nhas_keyLien vers cette rubrique#Renvoie les objets dont les données contiennent la clé indiquée. Utilise l’opérateur SQL ?. Par exemple :
>>> Dog.objects.create(name="Rufus", data={"breed": "labrador"})\n>>> Dog.objects.create(name="Meg", data={"breed": "collie", "owner": "Bob"})\n\n>>> Dog.objects.filter(data__has_key="owner")\n<QuerySet [<Dog: Meg>]>\nhas_any_keysLien vers cette rubrique#Renvoie les objets dont les données contiennent au moins une des clés indiquées. Utilise l’opérateur SQL ?|. Par exemple :
>>> Dog.objects.create(name="Rufus", data={"breed": "labrador"})\n>>> Dog.objects.create(name="Meg", data={"owner": "Bob"})\n>>> Dog.objects.create(name="Fred", data={})\n\n>>> Dog.objects.filter(data__has_any_keys=["owner", "breed"])\n<QuerySet [<Dog: Rufus>, <Dog: Meg>]>\nhas_keysLien vers cette rubrique#Renvoie les objets dont les données contiennent toutes les clés indiquées. Utilise l’opérateur SQL ?&. Par exemple :
>>> Dog.objects.create(name="Rufus", data={})\n>>> Dog.objects.create(name="Meg", data={"breed": "collie", "owner": "Bob"})\n\n>>> Dog.objects.filter(data__has_keys=["breed", "owner"])\n<QuerySet [<Dog: Meg>]>\nkeysLien vers cette rubrique#Renvoie l’ensemble des clés des objets concernés. Notez que l’ordre n’est pas garanti, ce qui fait que cette transformation est surtout utile quand elle est combinée à des recherches sur ArrayField. Utilise la fonction SQL akeys(). Par exemple :
>>> Dog.objects.create(name="Rufus", data={"toy": "bone"})\n>>> Dog.objects.create(name="Meg", data={"breed": "collie", "owner": "Bob"})\n\n>>> Dog.objects.filter(data__keys__overlap=["breed", "toy"])\n<QuerySet [<Dog: Rufus>, <Dog: Meg>]>\nvaluesLien vers cette rubrique#Renvoie l’ensemble des valeurs des objets concernés. Notez que l’ordre n’est pas garanti, ce qui fait que cette transformation est surtout utile quand elle est combinée à des recherches sur ArrayField. Utilise la fonction SQL avals(). Par exemple :
>>> Dog.objects.create(name="Rufus", data={"breed": "labrador"})\n>>> Dog.objects.create(name="Meg", data={"breed": "collie", "owner": "Bob"})\n\n>>> Dog.objects.filter(data__values__contains=["collie"])\n<QuerySet [<Dog: Meg>]>\nIl existe cinq types de champs d’intervalle, correspondant au types d’intervalles natifs de PostgreSQL. Ces champs sont utilisés pour stocker un intervalle de valeurs ; par exemple, l’heure de début et de fin d’un événement ou l’intervalle des âges appropriés à une activité.
\nTous les champs d’intervalle produisent des objets psycopg Range en Python, mais acceptent aussi des tuples en entrée si aucune information de limite n’est nécessaire. Par défaut, la limite inférieure est incluse et la limite supérieure exclue ; c’est-à-dire [) (consultez la documentation PostgreSQL pour plus de détails sur les différentes limites). Les limites par défaut peuvent être modifiées pour les champs d’intervalle de type non discret (DateTimeRangeField et DecimalRangeField) en utilisant l’argument default_bounds.
IntegerRangeFieldLien vers cette rubrique#Stocke un intervalle de nombres entiers. Basé sur un IntegerField. Représenté par un int4range dans la base de données et un django.db.backends.postgresql.psycopg_any.NumericRange en Python.
Quelles que soient les limites indiquées lors de l’enregistrement des données, PostgreSQL renvoie toujours un intervalle dans sa forme canonique qui inclut la limite inférieure et exclut la limite supérieure, c’est-à-dire [).
BigIntegerRangeFieldLien vers cette rubrique#Stocke un intervalle de grands nombres entiers. Basé sur un BigIntegerField. Représenté par un int8range dans la base de données et un django.db.backends.postgresql.psycopg_any.NumericRange en Python.
Quelles que soient les limites indiquées lors de l’enregistrement des données, PostgreSQL renvoie toujours un intervalle dans sa forme canonique qui inclut la limite inférieure et exclut la limite supérieure, c’est-à-dire [).
DecimalRangeFieldLien vers cette rubrique#Stocke un intervalle de nombres à virgule flottante. Basé sur un DecimalField. Représenté par un numrange dans la base de données et un django.db.backends.postgresql.psycopg_any.NumericRange en Python.
Facultatif. La valeur de bounds pour les entrées de type liste et tuple. La valeur par défaut est d’inclure la limite inférieure et d’exclure la limite supérieure, donc [) (voir la documentation PostgreSQL pour plus de détails sur les différentes limites). default_bounds n’est pas utilisé pour les entrées django.db.backends.postgresql.psycopg_any.NumericRange.
DateTimeRangeFieldLien vers cette rubrique#Stocke un intervalle d’horodatages. Basé sur un DateTimeField. Représenté par un tstzrange dans la base de données et un django.db.backends.postgresql.psycopg_any.DateTimeTZRange en Python.
Facultatif. La valeur de bounds pour les entrées de type liste et tuple. La valeur par défaut est d’inclure la limite inférieure et d’exclure la limite supérieure, donc [) (voir la documentation PostgreSQL pour plus de détails sur les différentes limites). default_bounds n’est pas utilisé pour les entrées django.db.backends.postgresql.psycopg_any.DateTimeTZRange.
DateRangeFieldLien vers cette rubrique#Stocke un intervalle de dates. Basé sur un DateField. Représenté par un daterange dans la base de données et un django.db.backends.postgresql.psycopg_any.DateRange en Python.
Quelles que soient les limites indiquées lors de l’enregistrement des données, PostgreSQL renvoie toujours un intervalle dans sa forme canonique qui inclut la limite inférieure et exclut la limite supérieure, c’est-à-dire [).
Il existe un certain nombre de recherches et de transformations spécifiques aux champs d’intervalle. Ils sont disponibles pour tous les champs ci-dessus, mais nous allons utiliser le modèle d’exemple suivant :
\nfrom django.contrib.postgres.fields import IntegerRangeField\nfrom django.db import models\n\n\nclass Event(models.Model):\n name = models.CharField(max_length=200)\n ages = IntegerRangeField()\n start = models.DateTimeField()\n\n def __str__(self):\n return self.name\nNous allons aussi utiliser les objets d’exemple suivants :
\n>>> import datetime\n>>> from django.utils import timezone\n>>> now = timezone.now()\n>>> Event.objects.create(name="Soft play", ages=(0, 10), start=now)\n>>> Event.objects.create(\n... name="Pub trip", ages=(21, None), start=now - datetime.timedelta(days=1)\n... )\net NumericRange:
>>> from django.db.backends.postgresql.psycopg_any import NumericRange\nComme pour les autres champs PostgreSQL, trois opérateurs de contenance standard sont disponibles : contains, contained_by et overlap, utilisant respectivement les opérateurs SQL @>, <@ et &&.
containsLien vers cette rubrique#>>> Event.objects.filter(ages__contains=NumericRange(4, 5))\n<QuerySet [<Event: Soft play>]>\ncontained_byLien vers cette rubrique#>>> Event.objects.filter(ages__contained_by=NumericRange(0, 15))\n<QuerySet [<Event: Soft play>]>\nLa recherche contained_by est aussi disponible pour les types de champ autres que intervalle : SmallAutoField, AutoField, BigAutoField, SmallIntegerField, IntegerField, BigIntegerField, DecimalField, FloatField, DateField et DateTimeField. Par exemple :
>>> from django.db.backends.postgresql.psycopg_any import DateTimeTZRange\n>>> Event.objects.filter(\n... start__contained_by=DateTimeTZRange(\n... timezone.now() - datetime.timedelta(hours=1),\n... timezone.now() + datetime.timedelta(hours=1),\n... ),\n... )\n<QuerySet [<Event: Soft play>]>\noverlapLien vers cette rubrique#>>> Event.objects.filter(ages__overlap=NumericRange(8, 12))\n<QuerySet [<Event: Soft play>]>\nLes champs d’intervalle prennent en charge les recherches standard : lt, gt, lte et gte. Elles ne sont pas particulièrement utiles, la comparaison s’opère d’abord sur la limite inférieure et si nécessaire, sur la limite supérieure ensuite. C’est également la stratégie adoptée pour trier selon un champ d’intervalle. Il est recommandé d’utiliser plutôt les opérateurs spécifiques de comparaison d’intervalle.
fully_ltLien vers cette rubrique#Les intervalles renvoyés sont strictement inférieurs à l’intervalle transmis. En d’autres termes, tous les points d’un intervalle renvoyé sont plus petits que tous ceux de l’intervalle transmis.
\n>>> Event.objects.filter(ages__fully_lt=NumericRange(11, 15))\n<QuerySet [<Event: Soft play>]>\nfully_gtLien vers cette rubrique#Les intervalles renvoyés sont strictement supérieurs à l’intervalle transmis. En d’autres termes, tous les points d’un intervalle renvoyé sont plus grands que tous ceux de l’intervalle transmis.
\n>>> Event.objects.filter(ages__fully_gt=NumericRange(11, 15))\n<QuerySet [<Event: Pub trip>]>\nnot_ltLien vers cette rubrique#Les intervalles renvoyés ne contiennent aucun élément plus petit que ceux de l’intervalle transmis, c’est-à-dire que la limite inférieure d’un intervalle renvoyé est au moins égale à la limite inférieure de l’intervalle transmis.
\n>>> Event.objects.filter(ages__not_lt=NumericRange(0, 15))\n<QuerySet [<Event: Soft play>, <Event: Pub trip>]>\nnot_gtLien vers cette rubrique#Les intervalles renvoyés ne contiennent aucun élément plus grand que ceux de l’intervalle transmis, c’est-à-dire que la limite supérieure d’un intervalle renvoyé n’est pas plus grande que la limite supérieure de l’intervalle transmis.
\n>>> Event.objects.filter(ages__not_gt=NumericRange(3, 10))\n<QuerySet [<Event: Soft play>]>\nadjacent_toLien vers cette rubrique#Les intervalles renvoyés partagent une limite avec l’intervalle transmis.
\n>>> Event.objects.filter(ages__adjacent_to=NumericRange(10, 21))\n<QuerySet [<Event: Soft play>, <Event: Pub trip>]>\nLes champs d’intervalle acceptent plusieurs requêtes supplémentaires.
\nstartswithLien vers cette rubrique#Les objets renvoyés possèdent la limite inférieure indiquée. Peut être suivie par des recherches valides pour le champ de base.
\n>>> Event.objects.filter(ages__startswith=21)\n<QuerySet [<Event: Pub trip>]>\nendswithLien vers cette rubrique#Les objets renvoyés possèdent la limite supérieure indiquée. Peut être suivie par des recherches valides pour le champ de base.
\n>>> Event.objects.filter(ages__endswith=10)\n<QuerySet [<Event: Soft play>]>\nisemptyLien vers cette rubrique#Les objets renvoyés sont des intervalles vides. Peut être suivie par des recherches valides pour un champ BooleanField.
>>> Event.objects.filter(ages__isempty=True)\n<QuerySet []>\nlower_incLien vers cette rubrique#Renvoie les objets dont la limite inférieure est incluse ou exclue, selon la valeur booléenne transmise. Peut être suivie par des recherches valides pour un champ BooleanField.
>>> Event.objects.filter(ages__lower_inc=True)\n<QuerySet [<Event: Soft play>, <Event: Pub trip>]>\nlower_infLien vers cette rubrique#Renvoie les objets dont la limite inférieure est illimitée (infinie) ou limitée, selon la valeur booléenne transmise. Peut être suivie par des recherches valides pour un champ BooleanField.
>>> Event.objects.filter(ages__lower_inf=True)\n<QuerySet []>\nupper_incLien vers cette rubrique#Renvoie les objets dont la limite supérieure est incluse ou exclue, selon la valeur booléenne transmise. Peut être suivie par des recherches valides pour un champ BooleanField.
>>> Event.objects.filter(ages__upper_inc=True)\n<QuerySet []>\nupper_infLien vers cette rubrique#Renvoie les objets dont la limite supérieure est illimitée (infinie) ou limitée, selon la valeur booléenne transmise. Peut être suivie par des recherches valides pour un champ BooleanField.
>>> Event.objects.filter(ages__upper_inf=True)\n<QuerySet [<Event: Pub trip>]>\nPostgreSQL permet de définir ses propres types d’intervalle. Les implémentations de champs de modèle et de formulaire de Django utilisent les classes de base ci-dessous, et psycopg propose une fonction register_range() pour permettre l’utilisation de types d’intervalle personnalisés.
Classe de base pour les champs de modèle de type intervalle.
\nLa classe de champ de modèle à utiliser.
\nLe type d’intervalle à utiliser.
\nLa classe de champ de formulaire à utiliser. Doit être une sous-classe de django.contrib.postgres.forms.BaseRangeField.
Classe de base pour les champs de formulaire de type intervalle.
\nLe champ de formulaire à utiliser.
\nLe type d’intervalle à utiliser.
\nPostgreSQL fournit un ensemble d’opérateurs SQL pouvant être utilisés avec les types de données intervalle (voir la documentation PostgreSQL pour tous les détails sur les opérateurs d’intervalle). Cette classe est pensée comme une méthode utilitaire pour éviter des fautes de frappe. Les noms d’opérateurs se recoupent avec les noms de leur opérateur de requête correspondant.
\nclass RangeOperators:\n EQUAL = "="\n NOT_EQUAL = "<>"\n CONTAINS = "@>"\n CONTAINED_BY = "<@"\n OVERLAPS = "&&"\n FULLY_LT = "<<"\n FULLY_GT = ">>"\n NOT_LT = "&>"\n NOT_GT = "&<"\n ADJACENT_TO = "-|-"\nSi True (par défaut), la limite inférieure est inclusive ('['), sinon elle est exclusive ('(').
Si False (par défaut), la limite supérieure est exclusive ('('), sinon elle est inclusive (']').
Une expression RangeBoundary() représente les limites d’un intervalle. Elle peut être utilisée avec une fonction d’intervalle personnalisée qui reçoit des limites, par exemple pour définir ExclusionConstraint. Voir la documentation PostgreSQL pour tous les détails.