## 17.12. Version and Platform Compatibility

### 17.12.1. Previous PostgreSQL Versions

`add_missing_from` (`boolean`)

  When on, tables that are referenced by a query will be automatically added to the `FROM` clause if not already present. This behavior does not comply with the SQL standard and many people dislike it because it can mask mistakes (such as referencing a table where you should have referenced its alias). The default is `off`. This variable can be enabled for compatibility with releases of PostgreSQL prior to 8.1, where this behavior was allowed by default.

  Note that even when this variable is enabled, a warning message will be emitted for each implicit `FROM` entry referenced by a query. Users are encouraged to update their applications to not rely on this behavior, by adding all tables referenced by a query to the query's `FROM` clause (or its `USING` clause in the case of `DELETE`).

`regex_flavor` (`string`)

  The regular expression “flavor” can be set to `advanced`, `extended`, or `basic`. The default is `advanced`. The `extended` setting may be useful for exact backwards compatibility with pre-7.4 releases of PostgreSQL. See Section 9.7.3.1, “Regular Expression Details” for details.

`sql_inheritance` (`boolean`)

  This controls the inheritance semantics, in particular whether subtables are included by various commands by default. They were not included in versions prior to 7.1. If you need the old behavior you can set this variable to `off`, but in the long run you are encouraged to change your applications to use the `ONLY` key word to exclude subtables. See Section 5.8, “Inheritance” for more information about inheritance.

`backslash_quote` (`string`)

  This controls whether a quote mark can be represented by `\'` in a string literal. The preferred, SQL-standard way to represent a quote mark is by doubling it (`''`) but PostgreSQL has historically also accepted `\'`. However, use of `\'` creates security risks because in some client character set encodings, there are multibyte characters in which the last byte is numerically equivalent to ASCII `\`. If client-side code does escaping incorrectly then a SQL-injection attack is possible. This risk can be prevented by making the server reject queries in which a quote mark appears to be escaped by a backslash. The allowed values of `backslash_quote` are `on` (allow `\'` always), `off` (reject always), and `safe_encoding` (allow only if client encoding does not allow ASCII `\` within a multibyte character). `safe_encoding` is the default setting.

`default_with_oids` (`boolean`)

  This controls whether `CREATE TABLE` and `CREATE TABLE AS` include an OID column in newly-created tables, if neither `WITH OIDS` nor `WITHOUT OIDS` is specified. It also determines whether OIDs will be included in tables created by `SELECT INTO`. In PostgreSQL 8.1 `default_with_oids` is disabled by default; in prior versions of PostgreSQL, it was on by default.

  The use of OIDs in user tables is considered deprecated, so most installations should leave this variable disabled. Applications that require OIDs for a particular table should specify `WITH OIDS` when creating the table. This variable can be enabled for compatibility with old applications that do not follow this behavior.

`escape_string_warning` (`boolean`)

  When on, a warning is issued if a backslash (`\`) appears in an ordinary string literal (`'...'` syntax). The default is `off`.

  Escape string syntax (`E'...'`) should be used for escapes, because in future versions of PostgreSQL ordinary strings will have the standard-conforming behavior of treating backslashes literally.

### 17.12.2. Platform and Client Compatibility

`transform_null_equals` (`boolean`)

  When on, expressions of the form ``expr` = NULL` (or `NULL = `expr``) are treated as ``expr` IS NULL`, that is, they return true if `expr` evaluates to the null value, and false otherwise. The correct SQL-spec-compliant behavior of ``expr` = NULL` is to always return null (unknown). Therefore this option defaults to `off`.

  However, filtered forms in Microsoft Access generate queries that appear to use ``expr` = NULL` to test for null values, so if you use that interface to access the database you might want to turn this option on. Since expressions of the form ``expr` = NULL` always return the null value (using the correct interpretation) they are not very useful and do not appear often in normal applications, so this option does little harm in practice. But new users are frequently confused about the semantics of expressions involving null values, so this option is not on by default.

  Note that this option only affects the exact form `= NULL`, not other comparison operators or other expressions that are computationally equivalent to some expression involving the equals operator (such as `IN`). Thus, this option is not a general fix for bad programming.

  Refer to Section 9.2, “Comparison Operators” for related information.