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, � Détails des expressions rationnelles � 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.
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(1) et pg_dumpall(1).
Ce param�tre contr�le si les références de table doivent inclure les tables filles. La valeur par défaut est on, signifiant que les tables filles sont incluses (et de ce fait, un suffixe * est supposé par défaut. Si ce param�tre est désactivé (� off), les tables filles ne sont pas inclus (et de ce fait, le préfixe ONLY est ajouté). Le standard SQL requiert que les tables filles soient inclues, donc le param�trages off n'est pas conforme au standard. Cependant, il est fourni par compatibilité avec les versions PostgreSQL™ antérieures � la 7.1. Voir Section 5.8, � L'héritage � pour plus d'informations.
Désactiver sql_inheritance n'est pas conseillé car le comportement induis par cette configuration porte � faire beaucoup d'erreurs. Ceci n'est pas constaté lorsque ce param�tre est activé comme le demande le standard SQL. Les discussions sur l'héritage dans ce manuel supposent généralement que ce param�tre est configuré � on.
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, � Constantes cha�ne avec des échappements de style C �) 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, � Opérateurs de comparaison �.
Gestion des verrous
