17.12. Compatibilité de version et de plateforme

Lorsque ce paramètre est activé (on), les tables référencées par une requête sont automatiquement ajoutées à la clause FROM si elles n'y sont pas déjà présentes. Ce comportement n'est pas compatible avec le standard SQL et beaucoup de personnes ne l'aiment pas car elle masque les erreurs (comme de faire référence à une table à la place de son alias). Désactivé par défaut (off), ce paramètre peut être activé pour des raisons de compatibilité avec les versions antérieures à PostgreSQL™ 8.1, pour lesquelles ce comportement était activé par défaut.

Même lorsque cette variable est activée, un message d'avertissement est émis pour chaque entrée FROM implicite référencée par une requête. Les utilisateurs sont encouragés à mettre à jour leurs applications pour qu'elles ne s'appuient pas sur ce comportement. Il suffit pour cela d'ajouter toutes les tables référencées par une requête dans la clause FROM de cette requête (ou dans sa clause USING dans le cas d'un DELETE ).

Contrôle si l'analyseur de saisie de tableau reconnaît les NULL sans guillemets comme des éléments 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 supportaient 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. La façon préférée, conforme au standard SQL, de représenter un guillemet est de le doubler ('') 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 apparait 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 litérale conforme au standard, \ ne signifie que \. Ce paramètre affecte 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, si ni WITH OIDS ni WITHOUT OIDS ne sont précisées. Ce paramètre détermine aussi si les OID sont inclus dans les tables créés par SELECT INTO . Dans PostgreSQL™ 8.1, default_with_oids est désactivée (off) par défaut, contrairement aux versions précédentes.

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é si un antislash (\) apparaît dans une chaîne lité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 changera dans une prochaine version pour des raisons de compatibilité avec le standard SQL. Cette variable peut être activée pour aider à la détection des applications non conformes.

Contrôle si les chaînes ordinaires ('...') traitent les antislashs litéralement, comme cela est indiqué dans le standard SQL. Désactivé par défaut (off), ce paramètre ramène PostgreSQL™ à son comportement historique pour le traitement des antislashs comme caractères d'échappement. La valeur par défaut sera passée à on dans une prochaine version pour améliorer la compatibilité avec le standard. Les applications peuvent vérifier ce paramètre pour déterminer la façon dont elles doivent traiter les chaînes lité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 doitt être utilisée pour les applications traitant les antislashs comme des caractères d'échappement.