Contrôle si l'analyseur de saisie de tableau reconnaît NULL non-encadré par des guillemets comme élément de tableaux NULL. Activé par défaut (on), il autorise la saisie de valeurs NULL dans un tableau. Néanmoins, les versions de PostgreSQL antérieures à la 8.2 ne supportent pas les valeurs NULL dans les tableaux. De ce fait, ces versions traitent NULL comme une chaîne dont le contenu est « NULL ». Pour une compatibilité ascendante avec les applications nécessitant l'ancien comportement, ce paramètre peut être désactivé (off).

Il est possible de créer des valeurs de tableau contenant des valeurs NULL même quand cette variable est à off.

Contrôle si un guillemet simple peut être représenté par un \' dans une chaîne. Il est préférable, et conforme au standard SQL, de représenter un guillemet simple en le doublant ('') mais, historiquement, PostgreSQL a aussi accepté \'. Néanmoins, l'utilisation de \' présente des problèmes de sécurité car certains encodages client contiennent des caractères multi-octets dans lesquels le dernier octet est l'équivalent ASCII numérique d'un \. Si le code côté client ne fait pas un échappement correct, alors une attaque par injection SQL est possible. Ce risque peut être évité en s'assurant que le serveur rejette les requêtes dans lesquelles apparaît un guillemet échappé avec un antislash. Les valeurs autorisées de backslash_quote sont on (autorise \' en permanence), off (le rejette en permanence) et safe_encoding (ne l'autorise que si l'encodage client n'autorise pas l'ASCII \ dans un caractère multioctet). safe_encoding est le paramétrage par défaut.

Dans une chaîne littérale conforme au standard, \ ne signifie que \. Ce paramètre affecte seulement la gestion des chaînes non conformes, incluant la syntaxe de chaînes d'échappement (E'...').

Contrôle si les commandes CREATE TABLE et CREATE TABLE AS incluent une colonne OID dans les tables nouvellement créées, lorsque ni WITH OIDS ni WITHOUT OIDS ne sont précisées. Ce paramètre détermine également si les OID sont inclus dans les tables créées par SELECT INTO. Ce paramètre est désactivé (off) par défaut ; avec PostgreSQL 8.0 et les versions précédentes, il était activé par défaut.

L'utilisation d'OID dans les tables utilisateur est considérée comme obsolète. Il est donc préférable pour la plupart des installations de laisser ce paramètre désactivé. Les applications qui requièrent des OID pour une table particulière doivent préciser WITH OIDS lors de la création de la table. Cette variable peut être activée pour des raisons de compatibilité avec les anciennes applications qui ne suivent pas ce comportement.

S'il est activé (on), un message d'avertissement est affiché lorsqu'un antislash (\) apparaît dans une chaîne littérale ordinaire (syntaxe '...') et que standard_conforming_strings est désactivé. Il est activé par défaut (on).

Les applications qui souhaitent utiliser l'antislash comme échappement doivent être modifiées pour utiliser la syntaxe de chaîne d'échappement (E'...') car le comportement par défaut des chaînes ordinaires est maintenant de traiter les antislashs comme un caractère ordinaire, d'après le standard SQL. Cette variable peut être activée pour aider à localiser le code qui doit être changé

La « flaveur » des expressions rationnelles peut être configurée à advanced (avancée), extended (étendue) ou basic (basique). La valeur par défaut est advanced. La configuration extended peut être utile pour une compatibilité ascendante avec les versions antérieures à PostgreSQL 7.4. Voir Section 9.7.3.1 pour plus de détails.

Dans les versions antérieures à la 9.0, les « Large Objects » n'avaient pas de droits d'accès et étaient, en réalité, toujours lisibles et modifiables par tous les utilisateurs. L'activation de cette variable désactive les nouvelles vérifications sur les droits, pour améliorer la compatibilité avec les versions précédentes. Désactivé par défaut. Seuls les superutilisateurs peuvent modifier ce paramètre.

Configurer cette variable ne désactive pas toutes les vérifications de sécurité pour les « Large Objects » -- seulement ceux dont le comportement par défaut a changé avec PostgreSQL 9.0. Par exemple, lo_import() et lo_export() ont besoin de droits superutilisateur indépendants de cette configuration.

Lorsque activé, l'analyseur émettra un avertissement pour toutes les constructions qui pourraient avoir changé de signification depuis PostgreSQL 9.4 comme conséquence de changements dans la précédence des opérateurs. Cela est utile dans l'audit d'applications pour voir si des changements de précédence ont cassé quelque chose ; mais il n'est pas destiné à être maintenu actif en production, dans la mesure où il lancera des avertissements sur du code SQL standard parfaitement valide. La valeur par défaut est off.

Voir Section 4.1.6 pour plus d'informations.

Quand la base de données génère du SQL, ce paramètre force tous les identifiants à être entre guillemets, même s'ils ne sont pas (actuellement) des mots-clés. Ceci affectera la sortie de la commande EXPLAIN ainsi que le résultat des fonctions comme pg_get_viewdef. Voir aussi l'option --quote-all-identifiers de pg_dump et pg_dumpall.

Contrôle si les chaînes ordinaires ('...') traitent les antislashs littéralement, comme cela est indiqué dans le standard SQL. À partir de PostgreSQL 9.1, ce paramètre est activé par défaut, donc à on (les versions précédentes avaient off par défaut). Les applications peuvent vérifier ce paramètre pour déterminer la façon dont elles doivent traiter les chaînes littérales. La présence de ce paramètre indique aussi que la syntaxe de chaîne d'échappement (E'...') est supportée. La syntaxe de chaîne d'échappement (Section 4.1.2.2) doit être utilisée pour les applications traitant les antislashs comme des caractères d'échappement.

Cette variable permet la synchronisation des parcours séquentiels de grosses tables pour que les parcours concurrents lisent le même bloc à peu près au même moment, et donc partagent la charge d'entrées/sorties. Quand ce paramètre est activé, un parcours peut commencer au milieu de la table, aller jusqu'à la fin, puis « revenir au début » pour récupérer toutes les lignes, ce qui permet de le synchroniser avec l'activité de parcours déjà entamés. Il peut en résulter des modifications non prévisibles dans l'ordre des lignes renvoyées par les requêtes qui n'ont pas de clause ORDER BY. Désactiver ce paramètre assure un comportement identique aux versions précédant la 8.3 pour lesquelles un parcours séquentiel commence toujours au début de la table. Activé par défaut (on).

Lorsque ce paramètre est activé (on), les expressions de la forme expr = NULL (ou NULL = expr) sont traitées comme expr IS NULL, c'est-à-dire qu'elles renvoient vrai si expr s'évalue à la valeur NULL, et faux sinon. Le bon comportement, compatible avec le standard SQL, de expr = NULL est de toujours renvoyer NULL (inconnu). De ce fait, ce paramètre est désactivé par défaut.

Toutefois, les formulaires filtrés dans Microsoft Access engendrent des requêtes qui utilisent expr = NULL pour tester les valeurs NULL. Il peut donc être souhaitable, lorsque cette intarface est utilisée pour accéder à une base de données, d'activer ce paramètre. Comme les expressions de la forme expr = NULL renvoient toujours la valeur NULL (en utilisant l'interprétation du standard SQL), elles ne sont pas très utiles et n'apparaissent pas souvent dans les applications normales. De ce fait, ce paramètre a peu d'utilité en pratique. Mais la sémantique des expressions impliquant des valeurs NULL est souvent source de confusion pour les nouveaux utilisateurs. C'est pourquoi ce paramètre n'est pas activé par défaut.

Ce paramètre n'affecte que la forme exacte = NULL, pas les autres opérateurs de comparaison ou expressions équivalentes en terme de calcul à des expressions qui impliquent l'opérateur égal (tels que IN). De ce fait, ce paramètre ne doit pas être considéré comme un correctif général à une mauvaise programmation.

De plus amples informations sont disponibles dans la Section 9.2.