+ STRICT changes the function so that it is not
+ invoked if any of its arguments are null; instead, a null result
+ is assumed automatically. See
linkend="sql-createfunction"> for more information.
Change the volatility of the function to the specified
- type. See for more
- information about function volatility.
+ setting. See for details.
properties of a function to be modified, but does not provide the
ability to rename a function, make a function a security definer,
or change the owner, schema, or volatility of a function. The standard also
- requires the RESTRICT key word; it is optional in
+ requires the RESTRICT key word, which is optional in
Compatibility
-
ALTER SEQUENCE conforms with
SQL:2003,
+
ALTER SEQUENCE conforms to the
SQL+ standard,
except for the SET SCHEMA variant, which is a
-
+
Compatibility
- The CREATE CAST command conforms to SQL:2003,
- except that SQL:2003 does not make provisions for binary-compatible
+ The CREATE CAST command conforms to the
+ except that SQL does not make provisions for binary-compatible
types or extra arguments to implementation functions.
AS IMPLICIT is a PostgreSQL
extension, too.
constraints individually.
- <note>
+ <caution>
- Keep in mind also that declaring a function result value as a domain
+ At present, declaring a function result value as a domain
is pretty dangerous, because none of the PLs enforce domain constraints
- on their results.
+ on their results. You'll need to make sure that the function code itself
+ respects the constraints. In
PL/pgSQL, one possible+ workaround is to explicitly cast the result value to the domain type
+ when you return it.
PL/pgSQL does not enforce domain+ constraints for local variables within functions, either.
- note>
+ caution>
change even within a single table scan, so no optimizations can be
made. Relatively few database functions are volatile in this sense;
some examples are random(), currval(),
- timeofday(). Note that any function that has side-effects
- must be classified volatile, even if its result is quite predictable,
- to prevent calls from being optimized away; an example is
+ timeofday(). But note that any function that has
+ side-effects must be classified volatile, even if its result is quite
+ predictable, to prevent calls from being optimized away; an example is
setval().
- The key word EXTERNAL is present for SQL
- conformance but is optional since, unlike in SQL, this feature
- does not only apply to external functions.
+ The key word EXTERNAL is allowed for SQL
+ conformance, but it is optional since, unlike in SQL, this feature
+ applies to all functions not only external ones.
Compatibility
- A CREATE FUNCTION command is defined in SQL:2003.
+ A CREATE FUNCTION command is defined in SQL:1999 and later.
The
PostgreSQL version is similar but
not fully compatible. The attributes are not portable, neither are the
different available languages.
Compatibility
-
CREATE SEQUENCE is is specified in SQL:2003.-
PostgreSQL conforms with the standard, with the following exceptions:
+
CREATE SEQUENCE conforms to the SQL+ standard, with the following exceptions:
The standard's AS <data type> expression is not supported.
Obtaining the next value is done using the nextval() function instead of the standard's NEXT VALUE FOR expression.
-CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } ] TABLE table_name (
- [ column_name data_type [ DEFAULT default_expr ] [ column_constraint [ ... ] ]
+CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } ] TABLE table_name ( [
+ { column_name data_type [ DEFAULT default_expr ] [ column_constraint [ ... ] ]
| table_constraint
- | LIKE parent_table [ { INCLUDING | EXCLUDING } DEFAULTS ] ] [, ... ]
-)
+ | LIKE parent_table [ { INCLUDING | EXCLUDING } DEFAULTS ] }
+ [, ... ]
+] )
[ INHERITS ( parent_table [, ... ] ) ]
[ WITH OIDS | WITHOUT OIDS ]
[ ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP } ]
Compatibility
- The CREATE TABLE command conforms to SQL-92 and
- to a subset of SQL:2003, with exceptions listed below.
+ The CREATE TABLE command conforms to the
+
SQL standard, with exceptions listed below.
Multiple inheritance via the INHERITS clause is
a
PostgreSQL language extension.
- SQL:2003 defines single inheritance using a
- different syntax and different semantics. SQL:2003-style
+ SQL:1999 and later define single inheritance using a
+ different syntax and different semantics. SQL:1999-style
inheritance is not yet supported by
-CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } ] TABLE table_name [ (column_name [, ...] ) ] [ [ WITH | WITHOUT ] OIDS ]
+CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } ] TABLE table_name
+ [ (column_name [, ...] ) ] [ [ WITH | WITHOUT ] OIDS ]
AS query
Prior to
PostgreSQL 8.0,
CREATE TABLE AS always included OIDs in the table it
-
produced. As of
PostgreSQL 8.0,
+
created. As of
PostgreSQL 8.0,
the CREATE TABLE AS command allows the user to
explicitly specify whether OIDs should be included. If the
presence of OIDs is not explicitly specified,
the configuration variable is
- used. While this variable currently defaults to true, the default
- value may be changed in the future. Therefore, applications that
+ used. As of
PostgreSQL 8.1,
+ this variable is false by default, so the default behavior is not
+ identical to pre-8.0 releases. Applications that
require OIDs in the table created by CREATE TABLE
- AS should explicitly specify WITH
- OIDS to ensure compatibility with future versions
+ AS should explicitly specify WITH OIDS
+ to ensure proper behavior.
Compatibility
- CREATE TABLE AS is specified by the SQL:2003
- standard. There are some small differences between the definition
- of the command in SQL:2003 and its implementation in
+
CREATE TABLE AS conforms to the
SQL+ standard, with the following exceptions:
- The standard defines a WITH DATA clause;
+ The standard defines a WITH [ NO ] DATA clause;
this is not currently implemented by
PostgreSQL.+ The behavior provided by
PostgreSQL is equivalent+ to the standard's WITH DATA case.
+
+
+
+
+
WITH/WITHOUT OIDS is a PostgreSQL+ extension.
+
+
+
+
+
PostgreSQL handles temporary tables in a way+ rather different from the standard; see
+
+ for details.
The CREATE TRIGGER statement in
PostgreSQL implements a subset of the
- SQL:2003 standard. The following functionality is currently missing:
+
SQL standard. The following functionality is currently missing:
- SQL:2003 allows triggers to fire on updates to specific columns
+ SQL allows triggers to fire on updates to specific columns
(e.g., AFTER UPDATE OF col1, col2).
- SQL:2003 allows you to define aliases for the old
+ SQL allows you to define aliases for the old
and new
rows or tables for use in the definition
of the triggered action (e.g., CREATE TRIGGER ... ON
tablename REFERENCING OLD ROW AS somename NEW ROW AS othername
PostgreSQL only allows the execution
- of a user-defined function for the triggered action. SQL:2003
+ of a user-defined function for the triggered action. The standard
allows the execution of a number of other SQL commands, such as
- CREATE TABLE as triggered action. This
+ CREATE TABLE as the triggered action. This
limitation is not hard to work around by creating a user-defined
function that executes the desired commands.
- SQL:2003 specifies that multiple triggers should be fired in
+ SQL specifies that multiple triggers should be fired in
time-of-creation order.
PostgreSQL uses
name order, which was judged more convenient to work with.
This CREATE TYPE command is a
PostgreSQL extension. There is a
- CREATE TYPE statement in SQL:2003 that is rather
- different in detail.
+
CREATE TYPE statement in
the SQL standard+ that is rather different in detail.
-CREATE [ OR REPLACE ] [ TEMP | TEMPORARY ] VIEW
name [ (
-class="PARAMETER">column_name [, ...] ) ] AS query
+CREATE [ OR REPLACE ] [ TEMP | TEMPORARY ] VIEW name [ ( class="PARAMETER">column_name [, ...] ) ]
+ AS query
If specified, the view is created as a temporary view.
Temporary views are automatically dropped at the end of the
- current session. Temporary views are automatically placed in the
- current backend's local temporary schema, so it is illegal to
- specify a schema-qualified name for a temporary view. Existing
+ current session. Existing
permanent relations with the same name are not visible to the
current session while the temporary view exists, unless they are
referenced with schema-qualified names.
- If any of the base tables referenced by the view are temporary,
+ If any of the tables referenced by the view are temporary,
the view is created as a temporary view (whether
TEMPORARY is specified or not).
The SQL standard specifies some additional capabilities for the
CREATE VIEW statement:
-CREATE VIEW name [ ( column [, ...] ) ]
- AS query
+CREATE VIEW name [ ( column_name [, ...] ) ]
+ AS query
[ WITH [ CASCADED | LOCAL ] CHECK OPTION ]
CREATE OR REPLACE VIEW is a
PostgreSQL language extension.
+ So is the concept of a temporary view.
The new user will not be a superuser.
+ This is the default.
The new user will not be allowed to create databases.
+ This is the default.
The new user will not be allowed to create new roles.
+ This is the default.
By default, DELETE will delete rows in the
- specified table and all its subtables. If you wish to delete only
+ specified table and all its child tables. If you wish to delete only
from the specific table mentioned, you must use the
ONLY clause.
Parameters
+
+ ONLY
+
+ If specified, delete rows from the named table only. When not
+ specified, any tables inheriting from the named table are also processed.
+
+
+
+
table
to the list of tables that can be specified in the
linkend="sql-from" endterm="sql-from-title"> of a
SELECT statement; for example, an alias for
- the table name can be specified.
+ the table name can be specified. Do not repeat the target table
+ in the usinglist,
+ unless you wish to set up a self-join.
condition
- A value expression that returns a value of type
- boolean that determines the rows which are to be
+ An expression returning a value of type
+ boolean, which determines the rows that are to be
deleted.
Compatibility
- DROP SEQUENCE conforms with
-
SQL:2003, except that the standard only allows one
+
DROP SEQUENCE conforms
to the SQL+ standard, except that the standard only allows one
sequence to be dropped per command.
-
+
- The options , ,
+ The options , ,
+ , ,
+ , ,
+ , ,
, ,
, ,
and
are new in
PostgreSQL 8.1.
-
-
-
-
- Create the dump in the specified encoding. By default, the dump is
- created in the database encoding.
-
-
+
+
+
+
+ Create the dump in the specified character set encoding. By default,
+ the dump is created in the database encoding. (Another way to get the
+ same result is to set the PGCLIENTENCODING environment
+ variable to the desired dump encoding.)
+
+
-
- Output SQL standard SET SESSION AUTHORIZATION commands instead of
- ALTER OWNER commands. This makes the dump more standards compatible,
- but depending on the history of the objects in the dump, may not
- restore properly.
+ Output SQL-standard SET SESSION AUTHORIZATION commands
+ instead of ALTER OWNER commands to determine object
+ ownership. This makes the dump more standards compatible, but
+ depending on the history of the objects in the dump, may not restore
+ properly. Also, a dump using SET SESSION AUTHORIZATION
+ will certainly require superuser privileges to restore correctly,
+ whereas ALTER OWNER requires lesser privileges.
- Output SQL standard SET SESSION AUTHORIZATION commands instead of
- ALTER OWNER commands. This makes the dump more standards compatible,
- but depending on the history of the objects in the dump, may not
- restore properly.
+ Output SQL-standard SET SESSION AUTHORIZATION commands
+ instead of ALTER OWNER commands to determine object
+ ownership. This makes the dump more standards compatible, but
+ depending on the history of the objects in the dump, may not restore
+ properly.
-
+
- Restore only definitions and/or data in the named schema. Not to be
- confused with the option. This can be combined with
- option.
+ Restore only objects that are in the named schema. This can be
+ combined with the option to restore just a
+ specific table.
- Restore only the schema (data definitions), not the data.
- Sequence values will be reset.
+ Restore only the schema (data definitions), not the data (table
+ contents). Sequence current values will not be restored, either.
+ (Do not confuse this with the
+ uses the word schema in a different meaning.)
- Output SQL standard SET SESSION AUTHORIZATION
- commands instead of ALTER OWNER commands. This
- makes the dump more standards compatible, but depending on the
- history of the objects in the dump, may not restore properly.
+ Output SQL-standard SET SESSION AUTHORIZATION commands
+ instead of ALTER OWNER commands to determine object
+ ownership. This makes the dump more standards compatible, but
+ depending on the history of the objects in the dump, may not restore
+ properly.
- Write all query output into file
- class="parameter">filename in addition to the regular output source.
+ Write all query output into file
+ class="parameter">filename, in addition to the
+ normal output destination.
precede it by a backslash. Anything contained in single quotes is
furthermore subject to C-like substitutions for
\n (new line), \t (tab),
- \digits (octal),
+ \digits (octal), and
\xdigits (hexadecimal).
The filename that will be used to store the history list. The default
- value is ~/.psql_history. For example, using:
+ value is ~/.psql_history. For example, putting
\set HISTFILE ~/.psql_history- :DBNAME
- in
~/.psqlrc will get
psql to
- maintain a separate history for each database.
+ in ~/.psqlrc will cause
+
psql to maintain a separate history for
+ each database.
Compatibility
- This command conforms to the SQL:2003 standard. The standard
+ This command conforms to the
SQL standard. The standard
specifies that the key word SAVEPOINT is
mandatory, but
PostgreSQL allows it to
be omitted.
Compatibility
- The SQL:2003 standard specifies that the key word
+ The
SQL standard specifies that the key word
SAVEPOINT is mandatory, but PostgreSQL
- and
Oracle allow it to be omitted. SQL:2003 allows+ and
Oracle allow it to be omitted. SQL allows only WORK, not TRANSACTION, as a noise word
- after ROLLBACK. Also, SQL:2003 has an optional clause
+ after ROLLBACK. Also, SQL has an optional clause
AND [ NO ] CHAIN which is not currently supported by
PostgreSQL. Otherwise, this command conforms to
the SQL standard.
Namespace Available to <literal>GROUP BY</literal> and <literal>ORDER BY</literal>
- In the SQL:2003 standard, an ORDER BY clause may
+ In the SQL-92 standard, an ORDER BY clause may
only use result column names or numbers, while a GROUP
BY clause may only use expressions based on input column
names.
PostgreSQL extends each of
- SQL:2003 uses a slightly different definition which is not entirely upward
- compatible with SQL-92.
+ SQL:1999 and later use a slightly different definition which is not
+ entirely upward compatible with SQL-92.
In most cases, however,
PostgreSQL will interpret an ORDER BY or GROUP
- BY expression the same way SQL:2003 does.
+ BY expression the same way SQL:1999 does.
- During VACUUM execution, there can be a substantial
- increase in I/O traffic, which cause poor performance for other active
- sessions. Therefore, it is sometimes advisable to use
- the cost-based vacuum delay feature. See
- linkend="runtime" endterm="runtime-config-resource-vacuum-cost-title"> for more
- details.
+ VACUUM causes a substantial increase in I/O traffic,
+ which can cause poor performance for other active sessions. Therefore,
+ it is sometimes advisable to use the cost-based vacuum delay feature.
+ See for details.
-
+ -config-resource-vacuum-cost" endterm="runtime-config-resource-vacuum-cost-title">
projects / postgresql.git / commitdiff