</indexterm>
<para>
- Recall the <classname>weather</classname> and
- <classname>cities</classname> tables from <xref
+ Recall the <structname>weather</structname> and
+ <structname>cities</structname> tables from <xref
linkend="tutorial-sql"/>. Consider the following problem: You
want to make sure that no one can insert rows in the
- <classname>weather</classname> table that do not have a matching
- entry in the <classname>cities</classname> table. This is called
+ <structname>weather</structname> table that do not have a matching
+ entry in the <structname>cities</structname> table. This is called
maintaining the <firstterm>referential integrity</firstterm> of
your data. In simplistic database systems this would be
implemented (if at all) by first looking at the
- <classname>cities</classname> table to check if a matching record
+ <structname>cities</structname> table to check if a matching record
exists, and then inserting or rejecting the new
- <classname>weather</classname> records. This approach has a
+ <structname>weather</structname> records. This approach has a
number of problems and is very inconvenient, so
<productname>PostgreSQL</productname> can do this for you.
</para>
</para>
<para>
- Let's create two tables: A table <classname>cities</classname>
- and a table <classname>capitals</classname>. Naturally, capitals
+ Let's create two tables: A table <structname>cities</structname>
+ and a table <structname>capitals</structname>. Naturally, capitals
are also cities, so you want some way to show the capitals
implicitly when you list all cities. If you're really clever you
might invent some scheme like this:
</para>
<para>
- In this case, a row of <classname>capitals</classname>
+ In this case, a row of <structname>capitals</structname>
<firstterm>inherits</firstterm> all columns (<structfield>name</structfield>,
<structfield>population</structfield>, and <structfield>elevation</structfield>) from its
- <firstterm>parent</firstterm>, <classname>cities</classname>. The
+ <firstterm>parent</firstterm>, <structname>cities</structname>. The
type of the column <structfield>name</structfield> is
<type>text</type>, a native <productname>PostgreSQL</productname>
type for variable length character strings. The
- <classname>capitals</classname> table has
+ <structname>capitals</structname> table has
an additional column, <structfield>state</structfield>, which shows its
state abbreviation. In
<productname>PostgreSQL</productname>, a table can inherit from
<para>
Here the <literal>ONLY</literal> before <literal>cities</literal>
indicates that the query should be run over only the
- <classname>cities</classname> table, and not tables below
- <classname>cities</classname> in the inheritance hierarchy. Many
+ <structname>cities</structname> table, and not tables below
+ <structname>cities</structname> in the inheritance hierarchy. Many
of the commands that we have already discussed —
<command>SELECT</command>, <command>UPDATE</command>, and
<command>DELETE</command> — support this <literal>ONLY</literal>
);
</programlisting>
Without the specification of the column, the foreign key would also set
- the column <literal>tenant_id</literal> to null, but that column is still
+ the column <structfield>tenant_id</structfield> to null, but that column is still
required as part of the primary key.
</para>
<para>
As an example, suppose that user <literal>miriam</literal> creates
- table <literal>mytable</literal> and does:
+ table <structname>mytable</structname> and does:
<programlisting>
GRANT SELECT ON mytable TO PUBLIC;
GRANT SELECT, UPDATE, INSERT ON mytable TO admin;
<para>
Below is a larger example of how this feature can be used in production
- environments. The table <literal>passwd</literal> emulates a Unix password
+ environments. The table <structname>passwd</structname> emulates a Unix password
file:
</para>
in <xref linkend="xtypes"/>. The following example inserts the
complex type values <literal>(1,1)</literal>
and <literal>(3,3)</literal> into the
- columns <literal>a</literal> and <literal>b</literal>, and select
+ columns <structfield>a</structfield> and <structfield>b</structfield>, and select
them from the table after that.
<programlisting>
<literal>NESTED</literal> paths <literal>$.movies[*]</literal> and
<literal>$.books[*]</literal> and also the usage of
<literal>FOR ORDINALITY</literal> column at <literal>NESTED</literal>
- levels (columns <literal>movie_id</literal>, <literal>book_id</literal>,
- and <literal>author_id</literal>):
+ levels (columns <structfield>movie_id</structfield>, <structfield>book_id</structfield>,
+ and <structfield>author_id</structfield>):
<programlisting>
SELECT * FROM JSON_TABLE (
By default, B-tree indexes store their entries in ascending order
with nulls last (table TID is treated as a tiebreaker column among
otherwise equal entries). This means that a forward scan of an
- index on column <literal>x</literal> produces output satisfying <literal>ORDER BY x</literal>
+ index on column <structfield>x</structfield> produces output satisfying <literal>ORDER BY x</literal>
(or more verbosely, <literal>ORDER BY x ASC NULLS LAST</literal>). The
index can also be scanned backward, producing output satisfying
<literal>ORDER BY x DESC</literal>
indexes are best, but sometimes it's better to create separate indexes
and rely on the index-combination feature. For example, if your
workload includes a mix of queries that sometimes involve only column
- <literal>x</literal>, sometimes only column <literal>y</literal>, and sometimes both
+ <structfield>x</structfield>, sometimes only column <structfield>y</structfield>, and sometimes both
columns, you might choose to create two separate indexes on
- <literal>x</literal> and <literal>y</literal>, relying on index combination to
+ <structfield>x</structfield> and <structfield>y</structfield>, relying on index combination to
process the queries that use both columns. You could also create a
multicolumn index on <literal>(x, y)</literal>. This index would typically be
more efficient than index combination for queries involving both
columns, but as discussed in <xref linkend="indexes-multicolumn"/>, it
would be less useful for queries involving only <literal>y</literal>. Just
how useful will depend on how effective the B-tree index skip scan
- optimization is; if <literal>x</literal> has no more than several hundred
+ optimization is; if <structfield>x</structfield> has no more than several hundred
distinct values, skip scan will make searches for specific
- <literal>y</literal> values execute reasonably efficiently. A combination
+ <structfield>y</structfield> values execute reasonably efficiently. A combination
of a multicolumn index on <literal>(x, y)</literal> and a separate index on
- <literal>y</literal> might also serve reasonably well. For
- queries involving only <literal>x</literal>, the multicolumn index could be
+ <structfield>y</structfield> might also serve reasonably well. For
+ queries involving only <structfield>x</structfield>, the multicolumn index could be
used, though it would be larger and hence slower than an index on
- <literal>x</literal> alone. The last alternative is to create all three
+ <structfield>x</structfield> alone. The last alternative is to create all three
indexes, but this is probably only reasonable if the table is searched
much more often than it is updated and all three types of query are
common. If one of the types of query is much less common than the
<listitem>
<para>
The query must reference only columns stored in the index. For
- example, given an index on columns <literal>x</literal>
- and <literal>y</literal> of a table that also has a
- column <literal>z</literal>, these queries could use index-only scans:
+ example, given an index on columns <structfield>x</structfield>
+ and <structfield>y</structfield> of a table that also has a
+ column <structfield>z</structfield>, these queries could use index-only scans:
<programlisting>
SELECT x, y FROM tab WHERE x = 'key';
SELECT x FROM tab WHERE x = 'key' AND y < 42;
</para>
<para>
- Because column <literal>y</literal> is not part of the index's search
+ Because column <structfield>y</structfield> is not part of the index's search
key, it does not have to be of a data type that the index can handle;
it's merely stored in the index and is not interpreted by the index
machinery. Also, if the index is a unique index, that is
<programlisting>
CREATE UNIQUE INDEX tab_x_y ON tab(x) INCLUDE (y);
</programlisting>
- the uniqueness condition applies to just column <literal>x</literal>,
- not to the combination of <literal>x</literal> and <literal>y</literal>.
+ the uniqueness condition applies to just column <structfield>x</structfield>,
+ not to the combination of <structfield>x</structfield> and <structfield>y</structfield>.
(An <literal>INCLUDE</literal> clause can also be written
in <literal>UNIQUE</literal> and <literal>PRIMARY KEY</literal>
constraints, providing alternative syntax for setting up an index like
<programlisting>
CREATE INDEX tab_x_y ON tab(x, y);
</programlisting>
- even though they had no intention of ever using <literal>y</literal> as
+ even though they had no intention of ever using <structfield>y</structfield> as
part of a <literal>WHERE</literal> clause. This works fine as long as
the extra columns are trailing columns; making them be leading columns is
unwise for the reasons explained in <xref linkend="indexes-multicolumn"/>.
context <literal>f(x)</literal>, but the planner does not notice that and
concludes that an index-only scan is not possible. If an index-only scan
seems sufficiently worthwhile, this can be worked around by
- adding <literal>x</literal> as an included column, for example
+ adding <structfield>x</structfield> as an included column, for example
<programlisting>
CREATE INDEX tab_f_x ON tab (f(x)) INCLUDE (x);
</programlisting>
Since data types can be defined in a variety of ways in SQL, and
<productname>PostgreSQL</productname> contains additional ways to
define data types, their representation in the information schema
- can be somewhat difficult. The column <literal>data_type</literal>
+ can be somewhat difficult. The column <structfield>data_type</structfield>
is supposed to identify the underlying built-in type of the column.
In <productname>PostgreSQL</productname>, this means that the type
is defined in the system catalog schema
<literal>pg_catalog</literal>. This column might be useful if the
application can handle the well-known built-in types specially (for
example, format the numeric types differently or use the data in
- the precision columns). The columns <literal>udt_name</literal>,
- <literal>udt_schema</literal>, and <literal>udt_catalog</literal>
+ the precision columns). The columns <structfield>udt_name</structfield>,
+ <structfield>udt_schema</structfield>, and <structfield>udt_catalog</structfield>
always identify the underlying data type of the column, even if the
column is based on a domain. (Since
<productname>PostgreSQL</productname> treats built-in types like
type, because in that case it wouldn't matter if the column is
really based on a domain. If the column is based on a domain, the
identity of the domain is stored in the columns
- <literal>domain_name</literal>, <literal>domain_schema</literal>,
- and <literal>domain_catalog</literal>. If you want to pair up
+ <structfield>domain_name</structfield>, <structfield>domain_schema</structfield>,
+ and <structfield>domain_catalog</structfield>. If you want to pair up
columns with their associated data types and treat domains as
separate types, you could write <literal>coalesce(domain_name,
udt_name)</literal>, etc.
the sequence data type (see above). The precision indicates
the number of significant digits. It can be expressed in
decimal (base 10) or binary (base 2) terms, as specified in the
- column <literal>numeric_precision_radix</literal>.
+ column <structfield>numeric_precision_radix</structfield>.
</para></entry>
</row>
</para>
<para>
This column indicates in which base the values in the columns
- <literal>numeric_precision</literal> and
- <literal>numeric_scale</literal> are expressed. The value is
+ <structfield>numeric_precision</structfield> and
+ <structfield>numeric_scale</structfield> are expressed. The value is
either 2 or 10.
</para></entry>
</row>
of significant digits to the right of the decimal point. It
can be expressed in decimal (base 10) or binary (base 2) terms,
as specified in the column
- <literal>numeric_precision_radix</literal>.
+ <structfield>numeric_precision_radix</structfield>.
</para></entry>
</row>
</sect1>
<sect1 id="infoschema-sql-features">
- <title><literal>sql_features</literal></title>
+ <title><structname>sql_features</structname></title>
<para>
- The table <literal>sql_features</literal> contains information
+ The table <structname>sql_features</structname> contains information
about which formal features defined in the SQL standard are
supported by <productname>PostgreSQL</productname>. This is the
same information that is presented in <xref linkend="features"/>.
</sect1>
<sect1 id="infoschema-sql-implementation-info">
- <title><literal>sql_implementation_info</literal></title>
+ <title><structname>sql_implementation_info</structname></title>
<para>
- The table <literal>sql_implementation_info</literal> contains
+ The table <structname>sql_implementation_info</structname> contains
information about various aspects that are left
implementation-defined by the SQL standard. This information is
primarily intended for use in the context of the ODBC interface;
</sect1>
<sect1 id="infoschema-sql-parts">
- <title><literal>sql_parts</literal></title>
+ <title><structname>sql_parts</structname></title>
<para>
- The table <literal>sql_parts</literal> contains information about
+ The table <structname>sql_parts</structname> contains information about
which of the several parts of the SQL standard are supported by
<productname>PostgreSQL</productname>.
</para>
</sect1>
<sect1 id="infoschema-sql-sizing">
- <title><literal>sql_sizing</literal></title>
+ <title><structname>sql_sizing</structname></title>
<para>
- The table <literal>sql_sizing</literal> contains information about
+ The table <structname>sql_sizing</structname> contains information about
various size limits and maximum values in
<productname>PostgreSQL</productname>. This information is
primarily intended for use in the context of the ODBC interface;
in <productname>PostgreSQL</productname>) and distinct types (not
implemented in <productname>PostgreSQL</productname>). To be
future-proof, use the
- column <literal>user_defined_type_category</literal> to
+ column <structfield>user_defined_type_category</structfield> to
differentiate between these. Other user-defined types such as base
types and enums, which are <productname>PostgreSQL</productname>
extensions, are not shown here. For domains,
<para>
<literal>InvalidOid</literal> is returned if the column number is out of range,
or if the specified column is not a simple reference to a table column.
- You can query the system table <literal>pg_class</literal> to determine
+ You can query the system table <structname>pg_class</structname> to determine
exactly which table is referenced.
</para>
</para>
<para>
- You can query the system table <literal>pg_type</literal> to
+ You can query the system table <structname>pg_type</structname> to
obtain the names and properties of the various data types. The
<acronym>OID</acronym>s of the built-in data types are defined
in the file <filename>catalog/pg_type_d.h</filename>
<para>
Furthermore, because the initial data copy ignores the <literal>publish</literal>
operation, and because publication <literal>pub3a</literal> has no row filter,
- it means the copied table <literal>t3</literal> contains all rows even when
+ it means the copied table <structname>t3</structname> contains all rows even when
they do not match the row filter of publication <literal>pub3b</literal>.
<programlisting>
/* sub # */ SELECT * FROM t3;
<para>
Create some publications. Publication <literal>p1</literal> has one table
(<literal>t1</literal>) and that table has a row filter. Publication
- <literal>p2</literal> has two tables. Table <literal>t1</literal> has no row
- filter, and table <literal>t2</literal> has a row filter. Publication
+ <literal>p2</literal> has two tables. Table <structname>t1</structname> has no row
+ filter, and table <structname>t2</structname> has a row filter. Publication
<literal>p3</literal> has two tables, and both of them have a row filter.
<programlisting><![CDATA[
/* pub # */ CREATE PUBLICATION p1 FOR TABLE t1 WHERE (a > 5 AND c = 'NSW');
<para>
<command>psql</command> can be used to show the row filter expressions (if
- defined) for each table. See that table <literal>t1</literal> is a member
+ defined) for each table. See that table <structname>t1</structname> is a member
of two publications, but has a row filter only in <literal>p1</literal>.
- See that table <literal>t2</literal> is a member of two publications, and
+ See that table <structname>t2</structname> is a member of two publications, and
has a different row filter in each of them.
<programlisting><![CDATA[
/* pub # */ \d t1
]]></programlisting></para>
<para>
- On the subscriber node, create a table <literal>t1</literal> with the same
+ On the subscriber node, create a table <structname>t1</structname> with the same
definition as the one on the publisher, and also create the subscription
<literal>s1</literal> that subscribes to the publication <literal>p1</literal>.
<programlisting>
<title>Examples</title>
<para>
- Create a table <literal>t1</literal> to be used in the following example.
+ Create a table <structname>t1</structname> to be used in the following example.
<programlisting>
/* pub # */ CREATE TABLE t1(id int, a text, b text, c text, d text, e text, PRIMARY KEY(id));
</programlisting></para>
<para>
Create a publication <literal>p1</literal>. A column list is defined for
- table <literal>t1</literal> to reduce the number of columns that will be
+ table <structname>t1</structname> to reduce the number of columns that will be
replicated. Notice that the order of column names in the column list does
not matter.
<programlisting>
</programlisting></para>
<para>
- On the subscriber node, create a table <literal>t1</literal> which now
+ On the subscriber node, create a table <structname>t1</structname> which now
only needs a subset of the columns that were on the publisher table
- <literal>t1</literal>, and also create the subscription
+ <structname>t1</structname>, and also create the subscription
<literal>s1</literal> that subscribes to the publication
<literal>p1</literal>.
<programlisting>
</programlisting></para>
<para>
- On the publisher node, insert some rows to table <literal>t1</literal>.
+ On the publisher node, insert some rows to table <structname>t1</structname>.
<programlisting>
/* pub # */ INSERT INTO t1 VALUES(1, 'a-1', 'b-1', 'c-1', 'd-1', 'e-1');
/* pub # */ INSERT INTO t1 VALUES(2, 'a-2', 'b-2', 'c-2', 'd-2', 'e-2');
<para>
The above will start the replication process, which synchronizes the
- initial table contents of the tables <literal>users</literal> and
- <literal>departments</literal> and then starts replicating
+ initial table contents of the tables <structname>users</structname> and
+ <structname>departments</structname> and then starts replicating
incremental changes to those tables.
</para>
</sect1>
$rv = spi_exec_query('SELECT * FROM my_table', 5);
</programlisting>
This returns up to 5 rows from the table
- <literal>my_table</literal>. If <literal>my_table</literal>
- has a column <literal>my_column</literal>, you can get that
+ <structname>my_table</structname>. If <structname>my_table</structname>
+ has a column <structfield>my_column</structfield>, you can get that
value from row <literal>$i</literal> of the result like this:
<programlisting>
$foo = $rv->{rows}[$i]->{my_column};
<term><literal>$_TD->{new}{foo}</literal></term>
<listitem>
<para>
- <literal>NEW</literal> value of column <literal>foo</literal>
+ <literal>NEW</literal> value of column <structfield>foo</structfield>
</para>
</listitem>
</varlistentry>
<term><literal>$_TD->{old}{foo}</literal></term>
<listitem>
<para>
- <literal>OLD</literal> value of column <literal>foo</literal>
+ <literal>OLD</literal> value of column <structfield>foo</structfield>
</para>
</listitem>
</varlistentry>
</variablelist>
<para>
- To put this together, assume we have tables <literal>t1</literal>:
+ To put this together, assume we have tables <structname>t1</structname>:
<programlisting>
num | name
-----+------
2 | b
3 | c
</programlisting>
- and <literal>t2</literal>:
+ and <structname>t2</structname>:
<programlisting>
num | value
-----+-------
<para>
In the second query, we could not have written <literal>SELECT *
FROM test1 GROUP BY x</literal>, because there is no single value
- for the column <literal>y</literal> that could be associated with each
+ for the column <structfield>y</structfield> that could be associated with each
group. The grouped-by columns can be referenced in the select list since
they have a single value in each group.
</para>
<title>Examples</title>
<para>
- Cluster the table <literal>employees</literal> on the basis of
+ Cluster the table <structname>employees</structname> on the basis of
its index <literal>employees_ind</literal>:
<programlisting>
CLUSTER employees USING employees_ind;
</para>
<para>
- Cluster the <literal>employees</literal> table using the same
+ Cluster the <structname>employees</structname> table using the same
index that was used before:
<programlisting>
CLUSTER employees;
<title>Examples</title>
<para>
- Attach a comment to the table <literal>mytable</literal>:
+ Attach a comment to the table <structname>mytable</structname>:
<programlisting>
COMMENT ON TABLE mytable IS 'This is my table.';
<para>
Currently, <literal>CHECK</literal> expressions cannot contain
subqueries nor refer to variables other than columns of the
- current row. The system column <literal>tableoid</literal>
+ current row. The system column <structfield>tableoid</structfield>
may be referenced, but not any other system column.
</para>
SET search_path = admin, pg_temp;
</programlisting>
- This function's intention is to access a table <literal>admin.pwds</literal>.
+ This function's intention is to access a table <structname>admin.pwds</structname>.
But without the <literal>SET</literal> clause, or with a <literal>SET</literal> clause
mentioning only <literal>admin</literal>, the function could be subverted by
- creating a temporary table named <literal>pwds</literal>.
+ creating a temporary table named <structname>pwds</structname>.
</para>
<para>
<title>Examples</title>
<para>
- To create a unique B-tree index on the column <literal>title</literal> in
- the table <literal>films</literal>:
+ To create a unique B-tree index on the column <structfield>title</structfield> in
+ the table <structname>films</structname>:
<programlisting>
CREATE UNIQUE INDEX title_idx ON films (title);
</programlisting>
</para>
<para>
- To create a unique B-tree index on the column <literal>title</literal>
- with included columns <literal>director</literal>
- and <literal>rating</literal> in the table <literal>films</literal>:
+ To create a unique B-tree index on the column <structfield>title</structfield>
+ with included columns <structfield>director</structfield>
+ and <structfield>rating</structfield> in the table <structname>films</structname>:
<programlisting>
CREATE UNIQUE INDEX title_idx ON films (title) INCLUDE (director, rating);
</programlisting>
</para>
<para>
- To create an index on the column <literal>code</literal> in the table
- <literal>films</literal> and have the index reside in the tablespace
+ To create an index on the column <structfield>code</structfield> in the table
+ <structname>films</structname> and have the index reside in the tablespace
<literal>indexspace</literal>:
<programlisting>
CREATE INDEX code_idx ON films (code) TABLESPACE indexspace;
Currently, <literal>CHECK</literal> expressions cannot contain
subqueries nor refer to variables other than columns of the
current row (see <xref linkend="ddl-constraints-check-constraints"/>).
- The system column <literal>tableoid</literal>
+ The system column <structfield>tableoid</structfield>
may be referenced, but not any other system column.
</para>
<title>Examples</title>
<para>
- Create a new table <literal>films_recent</literal> consisting of only
- recent entries from the table <literal>films</literal>:
+ Create a new table <structname>films_recent</structname> consisting of only
+ recent entries from the table <structname>films</structname>:
<programlisting>
CREATE TABLE films_recent AS
</para>
<para>
- Create a new temporary table <literal>films_recent</literal>, consisting of
- only recent entries from the table <literal>films</literal>, using a
+ Create a new temporary table <structname>films_recent</structname>, consisting of
+ only recent entries from the table <structname>films</structname>, using a
prepared statement. The new table will be dropped at commit:
<programlisting>
to change even when the trigger is not fired, because changes made to the
row's contents by <literal>BEFORE UPDATE</literal> triggers are not considered.
Conversely, a command such as <literal>UPDATE ... SET x = x ...</literal>
- will fire a trigger on column <literal>x</literal>, even though the column's
+ will fire a trigger on column <structfield>x</structfield>, even though the column's
value did not change.
</para>
<para>
Execute the function <function>check_account_update</function> whenever
- a row of the table <literal>accounts</literal> is about to be updated:
+ a row of the table <structname>accounts</structname> is about to be updated:
<programlisting>
CREATE TRIGGER check_update
</programlisting>
Modify that trigger definition to only execute the function if
- column <literal>balance</literal> is specified as a target in
+ column <structfield>balance</structfield> is specified as a target in
the <command>UPDATE</command> command:
<programlisting>
EXECUTE FUNCTION check_account_update();
</programlisting>
- This form only executes the function if column <literal>balance</literal>
+ This form only executes the function if column <structfield>balance</structfield>
has in fact changed value:
<programlisting>
EXECUTE FUNCTION check_account_update();
</programlisting>
- Call a function to log updates of <literal>accounts</literal>, but only if
+ Call a function to log updates of <structname>accounts</structname>, but only if
something changed:
<programlisting>
WHERE kind = 'Comedy';
</programlisting>
This will create a view containing the columns that are in the
- <literal>film</literal> table at the time of view creation. Though
+ <structname>film</structname> table at the time of view creation. Though
<literal>*</literal> was used to create the view, columns added later to
the table will not be part of the view.
</para>
WHERE classification = 'U'
WITH LOCAL CHECK OPTION;
</programlisting>
- This will create a view based on the <literal>comedies</literal> view, showing
+ This will create a view based on the <structname>comedies</structname> view, showing
only films with <literal>kind = 'Comedy'</literal> and
<literal>classification = 'U'</literal>. Any attempt to <command>INSERT</command> or
<command>UPDATE</command> a row in the view will be rejected if the new row
doesn't have <literal>classification = 'U'</literal>, but the film
- <literal>kind</literal> will not be checked.
+ <structfield>kind</structfield> will not be checked.
</para>
<para>
WHERE classification = 'PG'
WITH CASCADED CHECK OPTION;
</programlisting>
- This will create a view that checks both the <literal>kind</literal> and
- <literal>classification</literal> of new rows.
+ This will create a view that checks both the <structfield>kind</structfield> and
+ <structfield>classification</structfield> of new rows.
</para>
<para>
WHERE f.kind = 'Comedy';
</programlisting>
This view will support <command>INSERT</command>, <command>UPDATE</command> and
- <command>DELETE</command>. All the columns from the <literal>films</literal> table will
- be updatable, whereas the computed columns <literal>country</literal> and
- <literal>avg_rating</literal> will be read-only.
+ <command>DELETE</command>. All the columns from the <structname>films</structname> table will
+ be updatable, whereas the computed columns <structfield>country</structfield> and
+ <structfield>avg_rating</structfield> will be read-only.
</para>
<para>
</para>
<para>
- Clear the table <literal>films</literal>:
+ Clear the table <structname>films</structname>:
<programlisting>
DELETE FROM films;
</programlisting>
<title>Examples</title>
<para>
- Grant insert privilege to all users on table <literal>films</literal>:
+ Grant insert privilege to all users on table <structname>films</structname>:
<programlisting>
GRANT INSERT ON films TO PUBLIC;
<para>
Grant all available privileges to user <literal>manuel</literal> on view
- <literal>kinds</literal>:
+ <structname>kinds</structname>:
<programlisting>
GRANT ALL PRIVILEGES ON kinds TO manuel;
</programlisting>
Note that while the above will indeed grant all privileges if executed by a
- superuser or the owner of <literal>kinds</literal>, when executed by someone
+ superuser or the owner of <structname>kinds</structname>, when executed by someone
else it will only grant those permissions for which the someone else has
grant options.
</para>
<title>Examples</title>
<para>
- Insert a single row into table <literal>films</literal>:
+ Insert a single row into table <structname>films</structname>:
<programlisting>
INSERT INTO films VALUES
</para>
<para>
- In this example, the <literal>len</literal> column is
+ In this example, the <structfield>len</structfield> column is
omitted and therefore it will have the default value:
<programlisting>
<para>
This example inserts some rows into table
- <literal>films</literal> from a table <literal>tmp_films</literal>
- with the same column layout as <literal>films</literal>:
+ <structname>films</structname> from a table <structname>tmp_films</structname>
+ with the same column layout as <structname>films</structname>:
<programlisting>
INSERT INTO films SELECT * FROM tmp_films WHERE date_prod < '2004-05-07';
</para>
<para>
- Insert a single row into table <literal>distributors</literal>, returning
+ Insert a single row into table <structname>distributors</structname>, returning
the sequence number generated by the <literal>DEFAULT</literal> clause:
<programlisting>
<para>
Insert or update new distributors as appropriate. Assumes a unique
index has been defined that constrains values appearing in the
- <literal>did</literal> column. Note that the special
- <varname>excluded</varname> table is used to reference values originally
+ <structfield>did</structfield> column. Note that the special
+ <structname>excluded</structname> table is used to reference values originally
proposed for insertion:
<programlisting>
INSERT INTO distributors (did, dname)
<para>
Insert or update new distributors as above, returning information
about any existing values that were updated, together with the new data
- inserted. Note that the returned values for <literal>old_did</literal>
- and <literal>old_dname</literal> will be <literal>NULL</literal> for
+ inserted. Note that the returned values for <structfield>old_did</structfield>
+ and <structfield>old_dname</structfield> will be <literal>NULL</literal> for
non-conflicting rows:
<programlisting>
INSERT INTO distributors (did, dname)
when an existing, excluded row (a row with a matching constrained
column or columns after before row insert triggers fire) exists.
Example assumes a unique index has been defined that constrains
- values appearing in the <literal>did</literal> column:
+ values appearing in the <structfield>did</structfield> column:
<programlisting>
INSERT INTO distributors (did, dname) VALUES (7, 'Redline GmbH')
ON CONFLICT (did) DO NOTHING;
<para>
Insert or update new distributors as appropriate. Example assumes
a unique index has been defined that constrains values appearing in
- the <literal>did</literal> column. <literal>WHERE</literal> clause is
+ the <structfield>did</structfield> column. <literal>WHERE</literal> clause is
used to limit the rows actually updated (any existing row not
updated will still be locked, though):
<programlisting>
Insert new distributor if possible; otherwise
<literal>DO NOTHING</literal>. Example assumes a unique index has been
defined that constrains values appearing in the
- <literal>did</literal> column on a subset of rows where the
- <literal>is_active</literal> Boolean column evaluates to
+ <structfield>did</structfield> column on a subset of rows where the
+ <structfield>is_active</structfield> Boolean column evaluates to
<literal>true</literal>:
<programlisting>
-- This statement could infer a partial unique index on "did"
<para>
To dump all tables whose names start with <literal>mytable</literal>, except
- for table <literal>mytable2</literal>, specify a filter file
+ for table <structname>mytable2</structname>, specify a filter file
<filename>filter.txt</filename> like:
<programlisting>
include table mytable*
testdb=> <userinput>\set foo 'my_table'</userinput>
testdb=> <userinput>SELECT * FROM :foo;</userinput>
</programlisting>
- would query the table <literal>my_table</literal>. Note that this
+ would query the table <structname>my_table</structname>. Note that this
may be unsafe: the value of the variable is copied literally, so it can
contain unbalanced quotes, or even backslash commands. You must make sure
that it makes sense where you put it.
</para>
<para>
- Rebuild all the indexes on the table <literal>my_table</literal>:
+ Rebuild all the indexes on the table <structname>my_table</structname>:
<programlisting>
REINDEX TABLE my_table;
</para>
<para>
- To reindex the table <literal>foo</literal> and the index
+ To reindex the table <structname>foo</structname> and the index
<literal>bar</literal> in a database named <literal>abcd</literal>:
<screen>
<prompt>$ </prompt><userinput>reindexdb --table=foo --index=bar abcd</userinput>
<title>Examples</title>
<para>
- To join the table <literal>films</literal> with the table
- <literal>distributors</literal>:
+ To join the table <structname>films</structname> with the table
+ <structname>distributors</structname>:
<programlisting>
SELECT f.title, f.did, d.name, f.date_prod, f.kind
</para>
<para>
- To sum the column <literal>len</literal> of all films and group
- the results by <literal>kind</literal>:
+ To sum the column <structfield>len</structfield> of all films and group
+ the results by <structfield>kind</structfield>:
<programlisting>
SELECT kind, sum(len) AS total FROM films GROUP BY kind;
</para>
<para>
- To sum the column <literal>len</literal> of all films, group
- the results by <literal>kind</literal> and show those group totals
+ To sum the column <structfield>len</structfield> of all films, group
+ the results by <structfield>kind</structfield> and show those group totals
that are less than 5 hours:
<programlisting>
<para>
The following two examples are identical ways of sorting the individual
results according to the contents of the second column
- (<literal>name</literal>):
+ (<structfield>name</structfield>):
<programlisting>
SELECT * FROM distributors ORDER BY name;
<para>
The next example shows how to obtain the union of the tables
- <literal>distributors</literal> and
- <literal>actors</literal>, restricting the results to those that begin
+ <structname>distributors</structname> and
+ <structname>actors</structname>, restricting the results to those that begin
with the letter W in each table. Only distinct rows are wanted, so the
key word <literal>ALL</literal> is omitted.
<title>Examples</title>
<para>
- Create a new table <literal>films_recent</literal> consisting of only
- recent entries from the table <literal>films</literal>:
+ Create a new table <structname>films_recent</structname> consisting of only
+ recent entries from the table <structname>films</structname>:
<programlisting>
SELECT * INTO films_recent FROM films WHERE date_prod >= '2002-01-01';
<title>Examples</title>
<para>
- Truncate the tables <literal>bigtable</literal> and
- <literal>fattable</literal>:
+ Truncate the tables <structname>bigtable</structname> and
+ <structname>fattable</structname>:
<programlisting>
TRUNCATE bigtable, fattable;
</para>
<para>
- Truncate the table <literal>othertable</literal>, and cascade to any tables
- that reference <literal>othertable</literal> via foreign-key
+ Truncate the table <structname>othertable</structname>, and cascade to any tables
+ that reference <structname>othertable</structname> via foreign-key
constraints:
<programlisting>
<title>Examples</title>
<para>
- To clean a single table <literal>onek</literal>, analyze it for
+ To clean a single table <structname>onek</structname>, analyze it for
the optimizer and print a detailed vacuum activity report:
<programlisting>
command other than a <command>SELECT</command>, the result
relation points to the range-table entry where the result should
go. Everything else is absolutely the same. So having two tables
- <literal>t1</literal> and <literal>t2</literal> with columns <literal>a</literal> and
- <literal>b</literal>, the query trees for the two statements:
+ <structname>t1</structname> and <structname>t2</structname> with columns <structfield>a</structfield> and
+ <structfield>b</structfield>, the query trees for the two statements:
<programlisting>
SELECT t2.b FROM t1, t2 WHERE t1.a = t2.a;
<itemizedlist>
<listitem>
<para>
- The range tables contain entries for the tables <literal>t1</literal> and <literal>t2</literal>.
+ The range tables contain entries for the tables <structname>t1</structname> and <structname>t2</structname>.
</para>
</listitem>
<listitem>
<para>
The target lists contain one variable that points to column
- <literal>b</literal> of the range table entry for table <literal>t2</literal>.
+ <structfield>b</structfield> of the range table entry for table <structname>t2</structname>.
</para>
</listitem>
<listitem>
<para>
- The qualification expressions compare the columns <literal>a</literal> of both
+ The qualification expressions compare the columns <structfield>a</structfield> of both
range-table entries for equality.
</para>
</listitem>
<listitem>
<para>
- The join trees show a simple join between <literal>t1</literal> and <literal>t2</literal>.
+ The join trees show a simple join between <structname>t1</structname> and <structname>t2</structname>.
</para>
</listitem>
</itemizedlist>
<para>
The consequence is, that both query trees result in similar
execution plans: They are both joins over the two tables. For the
- <command>UPDATE</command> the missing columns from <literal>t1</literal> are added to
+ <command>UPDATE</command> the missing columns from <structname>t1</structname> are added to
the target list by the planner and the final query tree will read
as:
one is a <command>SELECT</command> command and the other is an
<command>UPDATE</command> is handled higher up in the executor, where
it knows that this is an <command>UPDATE</command>, and it knows that
- this result should go into table <literal>t1</literal>. But which of the rows
+ this result should go into table <structname>t1</structname>. But which of the rows
that are there has to be replaced by the new row?
</para>
This is a system column containing the
file block number and position in the block for the row. Knowing
the table, the <acronym>CTID</acronym> can be used to retrieve the
- original row of <literal>t1</literal> to be updated. After adding the
+ original row of <structname>t1</structname> to be updated. After adding the
<acronym>CTID</acronym> to the target list, the query actually looks like:
<programlisting>
WHERE sl_name = NEW.ok_name;
</programlisting>
- Now you can fill the table <literal>shoelace_arrive</literal> with
+ Now you can fill the table <structname>shoelace_arrive</structname> with
the data from the parts list:
<programlisting>
DELETE FROM computer WHERE hostname = 'mypc.local.net';
</programlisting>
- the table <literal>computer</literal> is scanned by index (fast), and the
+ the table <structname>computer</structname> is scanned by index (fast), and the
command issued by the trigger would also use an index scan (also fast).
The extra command from the rule would be:
This shows, that the planner does not realize that the
qualification for <structfield>hostname</structfield> in
- <literal>computer</literal> could also be used for an index scan on
- <literal>software</literal> when there are multiple qualification
+ <structname>computer</structname> could also be used for an index scan on
+ <structname>software</structname> when there are multiple qualification
expressions combined with <literal>AND</literal>, which is what it does
in the regular-expression version of the command. The trigger will
get invoked once for each of the 2000 old computers that have to be
deleted, and that will result in one index scan over
- <literal>computer</literal> and 2000 index scans over
- <literal>software</literal>. The rule implementation will do it with two
+ <structname>computer</structname> and 2000 index scans over
+ <structname>software</structname>. The rule implementation will do it with two
commands that use indexes. And it depends on the overall size of
- the table <literal>software</literal> whether the rule will still be faster in the
+ the table <structname>software</structname> whether the rule will still be faster in the
sequential scan situation. 2000 command executions from the trigger over the SPI
manager take some time, even if all the index blocks will soon be in the cache.
</para>
</programlisting>
Again this could result in many rows to be deleted from
- <literal>computer</literal>. So the trigger will again run many commands
+ <structname>computer</structname>. So the trigger will again run many commands
through the executor. The command generated by the rule will be:
<programlisting>
</programlisting>
The plan for that command will again be the nested loop over two
- index scans, only using a different index on <literal>computer</literal>:
+ index scans, only using a different index on <structname>computer</structname>:
<programlisting>
Nestloop
which will be expanded to a list of the elements of the row value,
just as occurs when the <literal>.*</literal> syntax is used at the top level
of a <command>SELECT</command> list (see <xref linkend="rowtypes-usage"/>).
- For example, if table <literal>t</literal> has
- columns <literal>f1</literal> and <literal>f2</literal>, these are the same:
+ For example, if table <structname>t</structname> has
+ columns <structfield>f1</structfield> and <structfield>f2</structfield>, these are the same:
<programlisting>
SELECT ROW(t.*, 42) FROM t;
SELECT ROW(t.f1, t.f2, 42) FROM t;
<para>
In this example, we chose the name <literal>accountno</literal> for the first
argument, but this is the same as the name of a column in the
- <literal>bank</literal> table. Within the <command>UPDATE</command> command,
- <literal>accountno</literal> refers to the column <literal>bank.accountno</literal>,
+ <structname>bank</structname> table. Within the <command>UPDATE</command> command,
+ <literal>accountno</literal> refers to the column <structfield>bank.accountno</structfield>,
so <literal>tf1.accountno</literal> must be used to refer to the argument.
We could of course avoid this by using a different name for the argument.
</para>
This feature is normally used when calling the function in the <literal>FROM</literal>
clause. In this case each row returned by the function becomes
a row of the table seen by the query. For example, assume that
- table <literal>foo</literal> has the same contents as above, and we say:
+ table <structname>foo</structname> has the same contents as above, and we say:
<programlisting>
CREATE FUNCTION getfoo(int) RETURNS SETOF foo AS $$
projects / thirdparty / postgresql.git / commitdiff
