Une fois activé, les tables référencées par une requête seront 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 référencer une table alors que vous avez référencé son alias). Désactivé par défaut (off). Cette variable peut être activée pour des raisons de compatibilité avec les versions précédant la 8.1 de PostgreSQL™ où ce comportement était activé par défaut.
Notez que même quand cette variable est activée, un message d'avertissement sera é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 ne pas se baser sur ce comportement, en ajoutant 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).
La « saveur » des expressions rationnelles peut être advanced (avancée), extended (étendue) ou basic (basique). La valeur par défaut est advanced. Le paramétrage extended peut être utile pour une compatibilité ascendante exacte avec les versions précédant la 7.4 de PostgreSQL™. Voir la Section 9.7.3.1, « Détails des expressions rationnelles » pour les détails.
Ceci contrôle la sémantique de l'héritage, en particulier si les sous-tables sont incluses par les différentes commandes par défaut. Elles ne l'étaient pas dans les versions antérieures à la 7.1. Si vous avez besoin de l'ancien comportement, vous pouvez désactiver cette variable mais, à long terme, vous êtes encouragé à changer vos applications pour utiliser le mot clé ONLY qui exclut les sous-tables. Voir la Section 5.8, « Héritage » pour plus d'informations sur les héritages.
Ceci contrôle si un guillemet peut être représenté par un \' dans une chaîne. Le moyen préféré, standard SQL, pour représenter un guillemet est de le doubler ('') mais, historiquement, PostgreSQL™ accepte aussi \'. Néanmoins, l'utilisation de \' ajoute des problèmes liés à la sécurité car certains codages d'ensembles de caractères des clients contiennent des caractères multi-octets dans lesquel le dernier octet est l'équivant 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 annihilé en s'assurant que le serveur rejette les requêtes dans lesquelles apparait un guillemet à échapper avec un antislash. Les valeurs autorisées de backslash_quote sont on (autorise \' en permanence), off (rejette en permanence) et safe_encoding (l'autorise seulement si le codage du client n'autorise pas l'ASCII \ dans un caractère multioctet). safe_encoding est le paramétrage par défaut.
Elle 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 spécifiées. Elle détermine aussi si les OID seront inclus dans les tables créés par SELECT INTO. Dans PostgreSQL™ 8.1, default_with_oids est désactivée contrairement aux versions précédentes.
L'utilisation d'OID dans les tables utilisateur est considérée comme obsolète, donc la plupart des installations devront laisser cette variable désactivée. Les applications qui requièrent des OID pour une table particulière devront spécifier 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.
Activé, un message d'avertissement est affiché si un antislash (\) apparaît dans une chaîne litérale ordinaire (syntaxe '...'). Désactivé par défaut (off).
La syntaxe des chaînes échappées (E'...') devrait être utilisée parce que les chaînes ordinaires des futures versions de PostgreSQL™ auront le comportement conforme au standard en traitant litéralement les antislashs.
Une fois activée, 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 par la valeur NULL, et faux sinon. Le bon comportement, compatible avec le standard SQL, de expr = NULL est de toujours renvoyer NULL (inconnu). Du coup, cette option est désactivée par défaut.
Néanmoins, les formulaires filtrés dans Microsoft Access™ génèrent des requêtes qui utilisent expr = NULL pour tester les valeurs NULL, donc si vous utilisez cette interface pour accéder à une base de données, vous souhaiterez activer cette option. Comme les expressions de la forme expr = NULL renvoient toujours la valeur NULL (en utilisant la bonne interprétation), elles ne sont pas très utiles et n'apparaissent pas souvent dans les applications normales, donc cette option a peu d'utilité en pratique. Mais les nouveaux utilisateurs confondent fréquemment la sémantique des expressions impliquant des valeurs NULL. Du coup, cette option n'est pas activée par défaut.
Notez que cette option affecte seulement la forme exacte = NULL, aucun autre opérateur de comparaison ou aucune autre expression qui sont équivalentes en terme de calcul à des expressions impliquant l'opérateur égal (telles que IN). Du coup, cette option n'est pas un correctif général pour une mauvaise programmation.
Référez-vous à la Section 9.2, « Opérateurs de comparaison » pour des informations en relation.
Gestion des verrous