mirror of
https://github.com/postgres/postgres.git
synced 2025-11-13 16:22:44 +03:00
doc: consistently use "structname" and "structfield" markup
Previously "literal" and "classname" were used, inconsistently, for SQL table and column names. Reported-by: Peter Smith Author: Peter Smith Discussion: https://postgr.es/m/CAHut+Pvtf24r+bdPgBind84dBLPvgNL7aB+=HxAUupdPuo2gRg@mail.gmail.com Backpatch-through: master
This commit is contained in:
@@ -80,18 +80,18 @@ SELECT * FROM myview;
|
|||||||
</indexterm>
|
</indexterm>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Recall the <classname>weather</classname> and
|
Recall the <structname>weather</structname> and
|
||||||
<classname>cities</classname> tables from <xref
|
<structname>cities</structname> tables from <xref
|
||||||
linkend="tutorial-sql"/>. Consider the following problem: You
|
linkend="tutorial-sql"/>. Consider the following problem: You
|
||||||
want to make sure that no one can insert rows in the
|
want to make sure that no one can insert rows in the
|
||||||
<classname>weather</classname> table that do not have a matching
|
<structname>weather</structname> table that do not have a matching
|
||||||
entry in the <classname>cities</classname> table. This is called
|
entry in the <structname>cities</structname> table. This is called
|
||||||
maintaining the <firstterm>referential integrity</firstterm> of
|
maintaining the <firstterm>referential integrity</firstterm> of
|
||||||
your data. In simplistic database systems this would be
|
your data. In simplistic database systems this would be
|
||||||
implemented (if at all) by first looking at the
|
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
|
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
|
number of problems and is very inconvenient, so
|
||||||
<productname>PostgreSQL</productname> can do this for you.
|
<productname>PostgreSQL</productname> can do this for you.
|
||||||
</para>
|
</para>
|
||||||
@@ -578,8 +578,8 @@ SELECT sum(salary) OVER w, avg(salary) OVER w
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Let's create two tables: A table <classname>cities</classname>
|
Let's create two tables: A table <structname>cities</structname>
|
||||||
and a table <classname>capitals</classname>. Naturally, capitals
|
and a table <structname>capitals</structname>. Naturally, capitals
|
||||||
are also cities, so you want some way to show the 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
|
implicitly when you list all cities. If you're really clever you
|
||||||
might invent some scheme like this:
|
might invent some scheme like this:
|
||||||
@@ -625,14 +625,14 @@ CREATE TABLE capitals (
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<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>,
|
<firstterm>inherits</firstterm> all columns (<structfield>name</structfield>,
|
||||||
<structfield>population</structfield>, and <structfield>elevation</structfield>) from its
|
<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 of the column <structfield>name</structfield> is
|
||||||
<type>text</type>, a native <productname>PostgreSQL</productname>
|
<type>text</type>, a native <productname>PostgreSQL</productname>
|
||||||
type for variable length character strings. The
|
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
|
an additional column, <structfield>state</structfield>, which shows its
|
||||||
state abbreviation. In
|
state abbreviation. In
|
||||||
<productname>PostgreSQL</productname>, a table can inherit from
|
<productname>PostgreSQL</productname>, a table can inherit from
|
||||||
@@ -685,8 +685,8 @@ SELECT name, elevation
|
|||||||
<para>
|
<para>
|
||||||
Here the <literal>ONLY</literal> before <literal>cities</literal>
|
Here the <literal>ONLY</literal> before <literal>cities</literal>
|
||||||
indicates that the query should be run over only the
|
indicates that the query should be run over only the
|
||||||
<classname>cities</classname> table, and not tables below
|
<structname>cities</structname> table, and not tables below
|
||||||
<classname>cities</classname> in the inheritance hierarchy. Many
|
<structname>cities</structname> in the inheritance hierarchy. Many
|
||||||
of the commands that we have already discussed —
|
of the commands that we have already discussed —
|
||||||
<command>SELECT</command>, <command>UPDATE</command>, and
|
<command>SELECT</command>, <command>UPDATE</command>, and
|
||||||
<command>DELETE</command> — support this <literal>ONLY</literal>
|
<command>DELETE</command> — support this <literal>ONLY</literal>
|
||||||
|
|||||||
@@ -1353,7 +1353,7 @@ CREATE TABLE posts (
|
|||||||
);
|
);
|
||||||
</programlisting>
|
</programlisting>
|
||||||
Without the specification of the column, the foreign key would also set
|
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.
|
required as part of the primary key.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
@@ -2831,7 +2831,7 @@ REVOKE ALL ON accounts FROM PUBLIC;
|
|||||||
|
|
||||||
<para>
|
<para>
|
||||||
As an example, suppose that user <literal>miriam</literal> creates
|
As an example, suppose that user <literal>miriam</literal> creates
|
||||||
table <literal>mytable</literal> and does:
|
table <structname>mytable</structname> and does:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
GRANT SELECT ON mytable TO PUBLIC;
|
GRANT SELECT ON mytable TO PUBLIC;
|
||||||
GRANT SELECT, UPDATE, INSERT ON mytable TO admin;
|
GRANT SELECT, UPDATE, INSERT ON mytable TO admin;
|
||||||
@@ -3059,7 +3059,7 @@ CREATE POLICY user_mod_policy ON users
|
|||||||
|
|
||||||
<para>
|
<para>
|
||||||
Below is a larger example of how this feature can be used in production
|
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:
|
file:
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
|
|||||||
@@ -1827,7 +1827,7 @@ while (1)
|
|||||||
in <xref linkend="xtypes"/>. The following example inserts the
|
in <xref linkend="xtypes"/>. The following example inserts the
|
||||||
complex type values <literal>(1,1)</literal>
|
complex type values <literal>(1,1)</literal>
|
||||||
and <literal>(3,3)</literal> into the
|
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.
|
them from the table after that.
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
|
|||||||
@@ -3899,8 +3899,8 @@ SELECT jt.* FROM
|
|||||||
<literal>NESTED</literal> paths <literal>$.movies[*]</literal> and
|
<literal>NESTED</literal> paths <literal>$.movies[*]</literal> and
|
||||||
<literal>$.books[*]</literal> and also the usage of
|
<literal>$.books[*]</literal> and also the usage of
|
||||||
<literal>FOR ORDINALITY</literal> column at <literal>NESTED</literal>
|
<literal>FOR ORDINALITY</literal> column at <literal>NESTED</literal>
|
||||||
levels (columns <literal>movie_id</literal>, <literal>book_id</literal>,
|
levels (columns <structfield>movie_id</structfield>, <structfield>book_id</structfield>,
|
||||||
and <literal>author_id</literal>):
|
and <structfield>author_id</structfield>):
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
SELECT * FROM JSON_TABLE (
|
SELECT * FROM JSON_TABLE (
|
||||||
|
|||||||
@@ -593,7 +593,7 @@ CREATE INDEX test2_mm_idx ON test2 (major, minor);
|
|||||||
By default, B-tree indexes store their entries in ascending order
|
By default, B-tree indexes store their entries in ascending order
|
||||||
with nulls last (table TID is treated as a tiebreaker column among
|
with nulls last (table TID is treated as a tiebreaker column among
|
||||||
otherwise equal entries). This means that a forward scan of an
|
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
|
(or more verbosely, <literal>ORDER BY x ASC NULLS LAST</literal>). The
|
||||||
index can also be scanned backward, producing output satisfying
|
index can also be scanned backward, producing output satisfying
|
||||||
<literal>ORDER BY x DESC</literal>
|
<literal>ORDER BY x DESC</literal>
|
||||||
@@ -698,23 +698,23 @@ CREATE INDEX test3_desc_index ON test3 (id DESC NULLS LAST);
|
|||||||
indexes are best, but sometimes it's better to create separate indexes
|
indexes are best, but sometimes it's better to create separate indexes
|
||||||
and rely on the index-combination feature. For example, if your
|
and rely on the index-combination feature. For example, if your
|
||||||
workload includes a mix of queries that sometimes involve only column
|
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
|
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
|
process the queries that use both columns. You could also create a
|
||||||
multicolumn index on <literal>(x, y)</literal>. This index would typically be
|
multicolumn index on <literal>(x, y)</literal>. This index would typically be
|
||||||
more efficient than index combination for queries involving both
|
more efficient than index combination for queries involving both
|
||||||
columns, but as discussed in <xref linkend="indexes-multicolumn"/>, it
|
columns, but as discussed in <xref linkend="indexes-multicolumn"/>, it
|
||||||
would be less useful for queries involving only <literal>y</literal>. Just
|
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
|
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
|
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
|
of a multicolumn index on <literal>(x, y)</literal> and a separate index on
|
||||||
<literal>y</literal> might also serve reasonably well. For
|
<structfield>y</structfield> might also serve reasonably well. For
|
||||||
queries involving only <literal>x</literal>, the multicolumn index could be
|
queries involving only <structfield>x</structfield>, the multicolumn index could be
|
||||||
used, though it would be larger and hence slower than an index on
|
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
|
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
|
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
|
common. If one of the types of query is much less common than the
|
||||||
@@ -1179,9 +1179,9 @@ CREATE INDEX mytable_cat_data ON mytable (category, data);
|
|||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
The query must reference only columns stored in the index. For
|
The query must reference only columns stored in the index. For
|
||||||
example, given an index on columns <literal>x</literal>
|
example, given an index on columns <structfield>x</structfield>
|
||||||
and <literal>y</literal> of a table that also has a
|
and <structfield>y</structfield> of a table that also has a
|
||||||
column <literal>z</literal>, these queries could use index-only scans:
|
column <structfield>z</structfield>, these queries could use index-only scans:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
SELECT x, y FROM tab WHERE x = 'key';
|
SELECT x, y FROM tab WHERE x = 'key';
|
||||||
SELECT x FROM tab WHERE x = 'key' AND y < 42;
|
SELECT x FROM tab WHERE x = 'key' AND y < 42;
|
||||||
@@ -1262,15 +1262,15 @@ CREATE INDEX tab_x_y ON tab(x) INCLUDE (y);
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<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;
|
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
|
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
|
machinery. Also, if the index is a unique index, that is
|
||||||
<programlisting>
|
<programlisting>
|
||||||
CREATE UNIQUE INDEX tab_x_y ON tab(x) INCLUDE (y);
|
CREATE UNIQUE INDEX tab_x_y ON tab(x) INCLUDE (y);
|
||||||
</programlisting>
|
</programlisting>
|
||||||
the uniqueness condition applies to just column <literal>x</literal>,
|
the uniqueness condition applies to just column <structfield>x</structfield>,
|
||||||
not to the combination of <literal>x</literal> and <literal>y</literal>.
|
not to the combination of <structfield>x</structfield> and <structfield>y</structfield>.
|
||||||
(An <literal>INCLUDE</literal> clause can also be written
|
(An <literal>INCLUDE</literal> clause can also be written
|
||||||
in <literal>UNIQUE</literal> and <literal>PRIMARY KEY</literal>
|
in <literal>UNIQUE</literal> and <literal>PRIMARY KEY</literal>
|
||||||
constraints, providing alternative syntax for setting up an index like
|
constraints, providing alternative syntax for setting up an index like
|
||||||
@@ -1300,7 +1300,7 @@ CREATE UNIQUE INDEX tab_x_y ON tab(x) INCLUDE (y);
|
|||||||
<programlisting>
|
<programlisting>
|
||||||
CREATE INDEX tab_x_y ON tab(x, y);
|
CREATE INDEX tab_x_y ON tab(x, y);
|
||||||
</programlisting>
|
</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
|
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
|
the extra columns are trailing columns; making them be leading columns is
|
||||||
unwise for the reasons explained in <xref linkend="indexes-multicolumn"/>.
|
unwise for the reasons explained in <xref linkend="indexes-multicolumn"/>.
|
||||||
@@ -1340,7 +1340,7 @@ SELECT f(x) FROM tab WHERE f(x) < 1;
|
|||||||
context <literal>f(x)</literal>, but the planner does not notice that and
|
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
|
concludes that an index-only scan is not possible. If an index-only scan
|
||||||
seems sufficiently worthwhile, this can be worked around by
|
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>
|
<programlisting>
|
||||||
CREATE INDEX tab_f_x ON tab (f(x)) INCLUDE (x);
|
CREATE INDEX tab_f_x ON tab (f(x)) INCLUDE (x);
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
|||||||
@@ -2089,15 +2089,15 @@
|
|||||||
Since data types can be defined in a variety of ways in SQL, and
|
Since data types can be defined in a variety of ways in SQL, and
|
||||||
<productname>PostgreSQL</productname> contains additional ways to
|
<productname>PostgreSQL</productname> contains additional ways to
|
||||||
define data types, their representation in the information schema
|
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.
|
is supposed to identify the underlying built-in type of the column.
|
||||||
In <productname>PostgreSQL</productname>, this means that the type
|
In <productname>PostgreSQL</productname>, this means that the type
|
||||||
is defined in the system catalog schema
|
is defined in the system catalog schema
|
||||||
<literal>pg_catalog</literal>. This column might be useful if the
|
<literal>pg_catalog</literal>. This column might be useful if the
|
||||||
application can handle the well-known built-in types specially (for
|
application can handle the well-known built-in types specially (for
|
||||||
example, format the numeric types differently or use the data in
|
example, format the numeric types differently or use the data in
|
||||||
the precision columns). The columns <literal>udt_name</literal>,
|
the precision columns). The columns <structfield>udt_name</structfield>,
|
||||||
<literal>udt_schema</literal>, and <literal>udt_catalog</literal>
|
<structfield>udt_schema</structfield>, and <structfield>udt_catalog</structfield>
|
||||||
always identify the underlying data type of the column, even if the
|
always identify the underlying data type of the column, even if the
|
||||||
column is based on a domain. (Since
|
column is based on a domain. (Since
|
||||||
<productname>PostgreSQL</productname> treats built-in types like
|
<productname>PostgreSQL</productname> treats built-in types like
|
||||||
@@ -2107,8 +2107,8 @@
|
|||||||
type, because in that case it wouldn't matter if the column is
|
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
|
really based on a domain. If the column is based on a domain, the
|
||||||
identity of the domain is stored in the columns
|
identity of the domain is stored in the columns
|
||||||
<literal>domain_name</literal>, <literal>domain_schema</literal>,
|
<structfield>domain_name</structfield>, <structfield>domain_schema</structfield>,
|
||||||
and <literal>domain_catalog</literal>. If you want to pair up
|
and <structfield>domain_catalog</structfield>. If you want to pair up
|
||||||
columns with their associated data types and treat domains as
|
columns with their associated data types and treat domains as
|
||||||
separate types, you could write <literal>coalesce(domain_name,
|
separate types, you could write <literal>coalesce(domain_name,
|
||||||
udt_name)</literal>, etc.
|
udt_name)</literal>, etc.
|
||||||
@@ -6376,7 +6376,7 @@ ORDER BY c.ordinal_position;
|
|||||||
the sequence data type (see above). The precision indicates
|
the sequence data type (see above). The precision indicates
|
||||||
the number of significant digits. It can be expressed in
|
the number of significant digits. It can be expressed in
|
||||||
decimal (base 10) or binary (base 2) terms, as specified in the
|
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>
|
</para></entry>
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
@@ -6386,8 +6386,8 @@ ORDER BY c.ordinal_position;
|
|||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
This column indicates in which base the values in the columns
|
This column indicates in which base the values in the columns
|
||||||
<literal>numeric_precision</literal> and
|
<structfield>numeric_precision</structfield> and
|
||||||
<literal>numeric_scale</literal> are expressed. The value is
|
<structfield>numeric_scale</structfield> are expressed. The value is
|
||||||
either 2 or 10.
|
either 2 or 10.
|
||||||
</para></entry>
|
</para></entry>
|
||||||
</row>
|
</row>
|
||||||
@@ -6402,7 +6402,7 @@ ORDER BY c.ordinal_position;
|
|||||||
of significant digits to the right of the decimal point. It
|
of significant digits to the right of the decimal point. It
|
||||||
can be expressed in decimal (base 10) or binary (base 2) terms,
|
can be expressed in decimal (base 10) or binary (base 2) terms,
|
||||||
as specified in the column
|
as specified in the column
|
||||||
<literal>numeric_precision_radix</literal>.
|
<structfield>numeric_precision_radix</structfield>.
|
||||||
</para></entry>
|
</para></entry>
|
||||||
</row>
|
</row>
|
||||||
|
|
||||||
@@ -6461,10 +6461,10 @@ ORDER BY c.ordinal_position;
|
|||||||
</sect1>
|
</sect1>
|
||||||
|
|
||||||
<sect1 id="infoschema-sql-features">
|
<sect1 id="infoschema-sql-features">
|
||||||
<title><literal>sql_features</literal></title>
|
<title><structname>sql_features</structname></title>
|
||||||
|
|
||||||
<para>
|
<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
|
about which formal features defined in the SQL standard are
|
||||||
supported by <productname>PostgreSQL</productname>. This is the
|
supported by <productname>PostgreSQL</productname>. This is the
|
||||||
same information that is presented in <xref linkend="features"/>.
|
same information that is presented in <xref linkend="features"/>.
|
||||||
@@ -6556,10 +6556,10 @@ ORDER BY c.ordinal_position;
|
|||||||
</sect1>
|
</sect1>
|
||||||
|
|
||||||
<sect1 id="infoschema-sql-implementation-info">
|
<sect1 id="infoschema-sql-implementation-info">
|
||||||
<title><literal>sql_implementation_info</literal></title>
|
<title><structname>sql_implementation_info</structname></title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The table <literal>sql_implementation_info</literal> contains
|
The table <structname>sql_implementation_info</structname> contains
|
||||||
information about various aspects that are left
|
information about various aspects that are left
|
||||||
implementation-defined by the SQL standard. This information is
|
implementation-defined by the SQL standard. This information is
|
||||||
primarily intended for use in the context of the ODBC interface;
|
primarily intended for use in the context of the ODBC interface;
|
||||||
@@ -6638,10 +6638,10 @@ ORDER BY c.ordinal_position;
|
|||||||
</sect1>
|
</sect1>
|
||||||
|
|
||||||
<sect1 id="infoschema-sql-parts">
|
<sect1 id="infoschema-sql-parts">
|
||||||
<title><literal>sql_parts</literal></title>
|
<title><structname>sql_parts</structname></title>
|
||||||
|
|
||||||
<para>
|
<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
|
which of the several parts of the SQL standard are supported by
|
||||||
<productname>PostgreSQL</productname>.
|
<productname>PostgreSQL</productname>.
|
||||||
</para>
|
</para>
|
||||||
@@ -6714,10 +6714,10 @@ ORDER BY c.ordinal_position;
|
|||||||
</sect1>
|
</sect1>
|
||||||
|
|
||||||
<sect1 id="infoschema-sql-sizing">
|
<sect1 id="infoschema-sql-sizing">
|
||||||
<title><literal>sql_sizing</literal></title>
|
<title><structname>sql_sizing</structname></title>
|
||||||
|
|
||||||
<para>
|
<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
|
various size limits and maximum values in
|
||||||
<productname>PostgreSQL</productname>. This information is
|
<productname>PostgreSQL</productname>. This information is
|
||||||
primarily intended for use in the context of the ODBC interface;
|
primarily intended for use in the context of the ODBC interface;
|
||||||
@@ -7843,7 +7843,7 @@ ORDER BY c.ordinal_position;
|
|||||||
in <productname>PostgreSQL</productname>) and distinct types (not
|
in <productname>PostgreSQL</productname>) and distinct types (not
|
||||||
implemented in <productname>PostgreSQL</productname>). To be
|
implemented in <productname>PostgreSQL</productname>). To be
|
||||||
future-proof, use the
|
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
|
differentiate between these. Other user-defined types such as base
|
||||||
types and enums, which are <productname>PostgreSQL</productname>
|
types and enums, which are <productname>PostgreSQL</productname>
|
||||||
extensions, are not shown here. For domains,
|
extensions, are not shown here. For domains,
|
||||||
|
|||||||
@@ -4508,7 +4508,7 @@ Oid PQftable(const PGresult *res,
|
|||||||
<para>
|
<para>
|
||||||
<literal>InvalidOid</literal> is returned if the column number is out of range,
|
<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.
|
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.
|
exactly which table is referenced.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
@@ -4578,7 +4578,7 @@ Oid PQftype(const PGresult *res,
|
|||||||
</para>
|
</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
|
obtain the names and properties of the various data types. The
|
||||||
<acronym>OID</acronym>s of the built-in data types are defined
|
<acronym>OID</acronym>s of the built-in data types are defined
|
||||||
in the file <filename>catalog/pg_type_d.h</filename>
|
in the file <filename>catalog/pg_type_d.h</filename>
|
||||||
|
|||||||
@@ -439,7 +439,7 @@
|
|||||||
<para>
|
<para>
|
||||||
Furthermore, because the initial data copy ignores the <literal>publish</literal>
|
Furthermore, because the initial data copy ignores the <literal>publish</literal>
|
||||||
operation, and because publication <literal>pub3a</literal> has no row filter,
|
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>.
|
they do not match the row filter of publication <literal>pub3b</literal>.
|
||||||
<programlisting>
|
<programlisting>
|
||||||
/* sub # */ SELECT * FROM t3;
|
/* sub # */ SELECT * FROM t3;
|
||||||
@@ -1036,8 +1036,8 @@ HINT: To initiate replication, you must manually create the replication slot, e
|
|||||||
<para>
|
<para>
|
||||||
Create some publications. Publication <literal>p1</literal> has one table
|
Create some publications. Publication <literal>p1</literal> has one table
|
||||||
(<literal>t1</literal>) and that table has a row filter. Publication
|
(<literal>t1</literal>) and that table has a row filter. Publication
|
||||||
<literal>p2</literal> has two tables. Table <literal>t1</literal> has no row
|
<literal>p2</literal> has two tables. Table <structname>t1</structname> has no row
|
||||||
filter, and table <literal>t2</literal> has a row filter. Publication
|
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.
|
<literal>p3</literal> has two tables, and both of them have a row filter.
|
||||||
<programlisting><![CDATA[
|
<programlisting><![CDATA[
|
||||||
/* pub # */ CREATE PUBLICATION p1 FOR TABLE t1 WHERE (a > 5 AND c = 'NSW');
|
/* pub # */ CREATE PUBLICATION p1 FOR TABLE t1 WHERE (a > 5 AND c = 'NSW');
|
||||||
@@ -1076,9 +1076,9 @@ Tables:
|
|||||||
|
|
||||||
<para>
|
<para>
|
||||||
<command>psql</command> can be used to show the row filter expressions (if
|
<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>.
|
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.
|
has a different row filter in each of them.
|
||||||
<programlisting><![CDATA[
|
<programlisting><![CDATA[
|
||||||
/* pub # */ \d t1
|
/* pub # */ \d t1
|
||||||
@@ -1121,7 +1121,7 @@ Publications:
|
|||||||
]]></programlisting></para>
|
]]></programlisting></para>
|
||||||
|
|
||||||
<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
|
definition as the one on the publisher, and also create the subscription
|
||||||
<literal>s1</literal> that subscribes to the publication <literal>p1</literal>.
|
<literal>s1</literal> that subscribes to the publication <literal>p1</literal>.
|
||||||
<programlisting>
|
<programlisting>
|
||||||
@@ -1474,14 +1474,14 @@ Publications:
|
|||||||
<title>Examples</title>
|
<title>Examples</title>
|
||||||
|
|
||||||
<para>
|
<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>
|
<programlisting>
|
||||||
/* pub # */ CREATE TABLE t1(id int, a text, b text, c text, d text, e text, PRIMARY KEY(id));
|
/* pub # */ CREATE TABLE t1(id int, a text, b text, c text, d text, e text, PRIMARY KEY(id));
|
||||||
</programlisting></para>
|
</programlisting></para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Create a publication <literal>p1</literal>. A column list is defined for
|
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
|
replicated. Notice that the order of column names in the column list does
|
||||||
not matter.
|
not matter.
|
||||||
<programlisting>
|
<programlisting>
|
||||||
@@ -1522,9 +1522,9 @@ Publications:
|
|||||||
</programlisting></para>
|
</programlisting></para>
|
||||||
|
|
||||||
<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
|
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>s1</literal> that subscribes to the publication
|
||||||
<literal>p1</literal>.
|
<literal>p1</literal>.
|
||||||
<programlisting>
|
<programlisting>
|
||||||
@@ -1535,7 +1535,7 @@ Publications:
|
|||||||
</programlisting></para>
|
</programlisting></para>
|
||||||
|
|
||||||
<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>
|
<programlisting>
|
||||||
/* pub # */ INSERT INTO t1 VALUES(1, 'a-1', 'b-1', 'c-1', 'd-1', 'e-1');
|
/* 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');
|
/* pub # */ INSERT INTO t1 VALUES(2, 'a-2', 'b-2', 'c-2', 'd-2', 'e-2');
|
||||||
@@ -3285,8 +3285,8 @@ CREATE SUBSCRIPTION mysub CONNECTION 'dbname=foo host=bar user=repuser' PUBLICAT
|
|||||||
|
|
||||||
<para>
|
<para>
|
||||||
The above will start the replication process, which synchronizes the
|
The above will start the replication process, which synchronizes the
|
||||||
initial table contents of the tables <literal>users</literal> and
|
initial table contents of the tables <structname>users</structname> and
|
||||||
<literal>departments</literal> and then starts replicating
|
<structname>departments</structname> and then starts replicating
|
||||||
incremental changes to those tables.
|
incremental changes to those tables.
|
||||||
</para>
|
</para>
|
||||||
</sect1>
|
</sect1>
|
||||||
|
|||||||
@@ -468,8 +468,8 @@ optional maximum number of rows:
|
|||||||
$rv = spi_exec_query('SELECT * FROM my_table', 5);
|
$rv = spi_exec_query('SELECT * FROM my_table', 5);
|
||||||
</programlisting>
|
</programlisting>
|
||||||
This returns up to 5 rows from the table
|
This returns up to 5 rows from the table
|
||||||
<literal>my_table</literal>. If <literal>my_table</literal>
|
<structname>my_table</structname>. If <structname>my_table</structname>
|
||||||
has a column <literal>my_column</literal>, you can get that
|
has a column <structfield>my_column</structfield>, you can get that
|
||||||
value from row <literal>$i</literal> of the result like this:
|
value from row <literal>$i</literal> of the result like this:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
$foo = $rv->{rows}[$i]->{my_column};
|
$foo = $rv->{rows}[$i]->{my_column};
|
||||||
@@ -1199,7 +1199,7 @@ $$ LANGUAGE plperl;
|
|||||||
<term><literal>$_TD->{new}{foo}</literal></term>
|
<term><literal>$_TD->{new}{foo}</literal></term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
<literal>NEW</literal> value of column <literal>foo</literal>
|
<literal>NEW</literal> value of column <structfield>foo</structfield>
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
@@ -1208,7 +1208,7 @@ $$ LANGUAGE plperl;
|
|||||||
<term><literal>$_TD->{old}{foo}</literal></term>
|
<term><literal>$_TD->{old}{foo}</literal></term>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
<literal>OLD</literal> value of column <literal>foo</literal>
|
<literal>OLD</literal> value of column <structfield>foo</structfield>
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
|||||||
@@ -410,7 +410,7 @@ FROM <replaceable>table_reference</replaceable> <optional>, <replaceable>table_r
|
|||||||
</variablelist>
|
</variablelist>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
To put this together, assume we have tables <literal>t1</literal>:
|
To put this together, assume we have tables <structname>t1</structname>:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
num | name
|
num | name
|
||||||
-----+------
|
-----+------
|
||||||
@@ -418,7 +418,7 @@ FROM <replaceable>table_reference</replaceable> <optional>, <replaceable>table_r
|
|||||||
2 | b
|
2 | b
|
||||||
3 | c
|
3 | c
|
||||||
</programlisting>
|
</programlisting>
|
||||||
and <literal>t2</literal>:
|
and <structname>t2</structname>:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
num | value
|
num | value
|
||||||
-----+-------
|
-----+-------
|
||||||
@@ -1079,7 +1079,7 @@ SELECT <replaceable>select_list</replaceable>
|
|||||||
<para>
|
<para>
|
||||||
In the second query, we could not have written <literal>SELECT *
|
In the second query, we could not have written <literal>SELECT *
|
||||||
FROM test1 GROUP BY x</literal>, because there is no single value
|
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
|
group. The grouped-by columns can be referenced in the select list since
|
||||||
they have a single value in each group.
|
they have a single value in each group.
|
||||||
</para>
|
</para>
|
||||||
|
|||||||
@@ -220,7 +220,7 @@ CLUSTER [ ( <replaceable class="parameter">option</replaceable> [, ...] ) ] [ <r
|
|||||||
<title>Examples</title>
|
<title>Examples</title>
|
||||||
|
|
||||||
<para>
|
<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>:
|
its index <literal>employees_ind</literal>:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
CLUSTER employees USING employees_ind;
|
CLUSTER employees USING employees_ind;
|
||||||
@@ -228,7 +228,7 @@ CLUSTER employees USING employees_ind;
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<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:
|
index that was used before:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
CLUSTER employees;
|
CLUSTER employees;
|
||||||
|
|||||||
@@ -301,7 +301,7 @@ COMMENT ON
|
|||||||
<title>Examples</title>
|
<title>Examples</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Attach a comment to the table <literal>mytable</literal>:
|
Attach a comment to the table <structname>mytable</structname>:
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
COMMENT ON TABLE mytable IS 'This is my table.';
|
COMMENT ON TABLE mytable IS 'This is my table.';
|
||||||
|
|||||||
@@ -360,7 +360,7 @@ WITH ( MODULUS <replaceable class="parameter">numeric_literal</replaceable>, REM
|
|||||||
<para>
|
<para>
|
||||||
Currently, <literal>CHECK</literal> expressions cannot contain
|
Currently, <literal>CHECK</literal> expressions cannot contain
|
||||||
subqueries nor refer to variables other than columns of the
|
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.
|
may be referenced, but not any other system column.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
|
|||||||
@@ -817,10 +817,10 @@ $$ LANGUAGE plpgsql
|
|||||||
SET search_path = admin, pg_temp;
|
SET search_path = admin, pg_temp;
|
||||||
</programlisting>
|
</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
|
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
|
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>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
|
|||||||
@@ -898,17 +898,17 @@ Indexes:
|
|||||||
<title>Examples</title>
|
<title>Examples</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
To create a unique B-tree index on the column <literal>title</literal> in
|
To create a unique B-tree index on the column <structfield>title</structfield> in
|
||||||
the table <literal>films</literal>:
|
the table <structname>films</structname>:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
CREATE UNIQUE INDEX title_idx ON films (title);
|
CREATE UNIQUE INDEX title_idx ON films (title);
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
To create a unique B-tree index on the column <literal>title</literal>
|
To create a unique B-tree index on the column <structfield>title</structfield>
|
||||||
with included columns <literal>director</literal>
|
with included columns <structfield>director</structfield>
|
||||||
and <literal>rating</literal> in the table <literal>films</literal>:
|
and <structfield>rating</structfield> in the table <structname>films</structname>:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
CREATE UNIQUE INDEX title_idx ON films (title) INCLUDE (director, rating);
|
CREATE UNIQUE INDEX title_idx ON films (title) INCLUDE (director, rating);
|
||||||
</programlisting>
|
</programlisting>
|
||||||
@@ -960,8 +960,8 @@ CREATE INDEX gin_idx ON documents_table USING GIN (locations) WITH (fastupdate =
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
To create an index on the column <literal>code</literal> in the table
|
To create an index on the column <structfield>code</structfield> in the table
|
||||||
<literal>films</literal> and have the index reside in the tablespace
|
<structname>films</structname> and have the index reside in the tablespace
|
||||||
<literal>indexspace</literal>:
|
<literal>indexspace</literal>:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
CREATE INDEX code_idx ON films (code) TABLESPACE indexspace;
|
CREATE INDEX code_idx ON films (code) TABLESPACE indexspace;
|
||||||
|
|||||||
@@ -862,7 +862,7 @@ WITH ( MODULUS <replaceable class="parameter">numeric_literal</replaceable>, REM
|
|||||||
Currently, <literal>CHECK</literal> expressions cannot contain
|
Currently, <literal>CHECK</literal> expressions cannot contain
|
||||||
subqueries nor refer to variables other than columns of the
|
subqueries nor refer to variables other than columns of the
|
||||||
current row (see <xref linkend="ddl-constraints-check-constraints"/>).
|
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.
|
may be referenced, but not any other system column.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
|
|||||||
@@ -266,8 +266,8 @@ CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } | UNLOGGED ] TABLE [ IF NOT EXI
|
|||||||
<title>Examples</title>
|
<title>Examples</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Create a new table <literal>films_recent</literal> consisting of only
|
Create a new table <structname>films_recent</structname> consisting of only
|
||||||
recent entries from the table <literal>films</literal>:
|
recent entries from the table <structname>films</structname>:
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
CREATE TABLE films_recent AS
|
CREATE TABLE films_recent AS
|
||||||
@@ -286,8 +286,8 @@ CREATE TABLE films2 AS
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Create a new temporary table <literal>films_recent</literal>, consisting of
|
Create a new temporary table <structname>films_recent</structname>, consisting of
|
||||||
only recent entries from the table <literal>films</literal>, using a
|
only recent entries from the table <structname>films</structname>, using a
|
||||||
prepared statement. The new table will be dropped at commit:
|
prepared statement. The new table will be dropped at commit:
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
|
|||||||
@@ -485,7 +485,7 @@ UPDATE OF <replaceable>column_name1</replaceable> [, <replaceable>column_name2</
|
|||||||
to change even when the trigger is not fired, because changes made to the
|
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.
|
row's contents by <literal>BEFORE UPDATE</literal> triggers are not considered.
|
||||||
Conversely, a command such as <literal>UPDATE ... SET x = x ...</literal>
|
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.
|
value did not change.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
@@ -598,7 +598,7 @@ UPDATE OF <replaceable>column_name1</replaceable> [, <replaceable>column_name2</
|
|||||||
|
|
||||||
<para>
|
<para>
|
||||||
Execute the function <function>check_account_update</function> whenever
|
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>
|
<programlisting>
|
||||||
CREATE TRIGGER check_update
|
CREATE TRIGGER check_update
|
||||||
@@ -608,7 +608,7 @@ CREATE TRIGGER check_update
|
|||||||
</programlisting>
|
</programlisting>
|
||||||
|
|
||||||
Modify that trigger definition to only execute the function if
|
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:
|
the <command>UPDATE</command> command:
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
@@ -618,7 +618,7 @@ CREATE OR REPLACE TRIGGER check_update
|
|||||||
EXECUTE FUNCTION check_account_update();
|
EXECUTE FUNCTION check_account_update();
|
||||||
</programlisting>
|
</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:
|
has in fact changed value:
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
@@ -629,7 +629,7 @@ CREATE TRIGGER check_update
|
|||||||
EXECUTE FUNCTION check_account_update();
|
EXECUTE FUNCTION check_account_update();
|
||||||
</programlisting>
|
</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:
|
something changed:
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
|
|||||||
@@ -492,7 +492,7 @@ CREATE VIEW comedies AS
|
|||||||
WHERE kind = 'Comedy';
|
WHERE kind = 'Comedy';
|
||||||
</programlisting>
|
</programlisting>
|
||||||
This will create a view containing the columns that are in the
|
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
|
<literal>*</literal> was used to create the view, columns added later to
|
||||||
the table will not be part of the view.
|
the table will not be part of the view.
|
||||||
</para>
|
</para>
|
||||||
@@ -507,12 +507,12 @@ CREATE VIEW universal_comedies AS
|
|||||||
WHERE classification = 'U'
|
WHERE classification = 'U'
|
||||||
WITH LOCAL CHECK OPTION;
|
WITH LOCAL CHECK OPTION;
|
||||||
</programlisting>
|
</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
|
only films with <literal>kind = 'Comedy'</literal> and
|
||||||
<literal>classification = 'U'</literal>. Any attempt to <command>INSERT</command> or
|
<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
|
<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
|
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>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
@@ -525,8 +525,8 @@ CREATE VIEW pg_comedies AS
|
|||||||
WHERE classification = 'PG'
|
WHERE classification = 'PG'
|
||||||
WITH CASCADED CHECK OPTION;
|
WITH CASCADED CHECK OPTION;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
This will create a view that checks both the <literal>kind</literal> and
|
This will create a view that checks both the <structfield>kind</structfield> and
|
||||||
<literal>classification</literal> of new rows.
|
<structfield>classification</structfield> of new rows.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
@@ -543,9 +543,9 @@ CREATE VIEW comedies AS
|
|||||||
WHERE f.kind = 'Comedy';
|
WHERE f.kind = 'Comedy';
|
||||||
</programlisting>
|
</programlisting>
|
||||||
This view will support <command>INSERT</command>, <command>UPDATE</command> and
|
This view will support <command>INSERT</command>, <command>UPDATE</command> and
|
||||||
<command>DELETE</command>. All the columns from the <literal>films</literal> table will
|
<command>DELETE</command>. All the columns from the <structname>films</structname> table will
|
||||||
be updatable, whereas the computed columns <literal>country</literal> and
|
be updatable, whereas the computed columns <structfield>country</structfield> and
|
||||||
<literal>avg_rating</literal> will be read-only.
|
<structfield>avg_rating</structfield> will be read-only.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
|
|||||||
@@ -285,7 +285,7 @@ DELETE FROM films WHERE kind <> 'Musical';
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Clear the table <literal>films</literal>:
|
Clear the table <structname>films</structname>:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
DELETE FROM films;
|
DELETE FROM films;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
|||||||
@@ -434,7 +434,7 @@ GRANT <replaceable class="parameter">role_name</replaceable> [, ...] TO <replace
|
|||||||
<title>Examples</title>
|
<title>Examples</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Grant insert privilege to all users on table <literal>films</literal>:
|
Grant insert privilege to all users on table <structname>films</structname>:
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
GRANT INSERT ON films TO PUBLIC;
|
GRANT INSERT ON films TO PUBLIC;
|
||||||
@@ -443,14 +443,14 @@ GRANT INSERT ON films TO PUBLIC;
|
|||||||
|
|
||||||
<para>
|
<para>
|
||||||
Grant all available privileges to user <literal>manuel</literal> on view
|
Grant all available privileges to user <literal>manuel</literal> on view
|
||||||
<literal>kinds</literal>:
|
<structname>kinds</structname>:
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
GRANT ALL PRIVILEGES ON kinds TO manuel;
|
GRANT ALL PRIVILEGES ON kinds TO manuel;
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
|
||||||
Note that while the above will indeed grant all privileges if executed by a
|
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
|
else it will only grant those permissions for which the someone else has
|
||||||
grant options.
|
grant options.
|
||||||
</para>
|
</para>
|
||||||
|
|||||||
@@ -654,7 +654,7 @@ INSERT <replaceable>oid</replaceable> <replaceable class="parameter">count</repl
|
|||||||
<title>Examples</title>
|
<title>Examples</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Insert a single row into table <literal>films</literal>:
|
Insert a single row into table <structname>films</structname>:
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
INSERT INTO films VALUES
|
INSERT INTO films VALUES
|
||||||
@@ -663,7 +663,7 @@ INSERT INTO films VALUES
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<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:
|
omitted and therefore it will have the default value:
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
@@ -704,8 +704,8 @@ INSERT INTO films (code, title, did, date_prod, kind) VALUES
|
|||||||
|
|
||||||
<para>
|
<para>
|
||||||
This example inserts some rows into table
|
This example inserts some rows into table
|
||||||
<literal>films</literal> from a table <literal>tmp_films</literal>
|
<structname>films</structname> from a table <structname>tmp_films</structname>
|
||||||
with the same column layout as <literal>films</literal>:
|
with the same column layout as <structname>films</structname>:
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
INSERT INTO films SELECT * FROM tmp_films WHERE date_prod < '2004-05-07';
|
INSERT INTO films SELECT * FROM tmp_films WHERE date_prod < '2004-05-07';
|
||||||
@@ -726,7 +726,7 @@ INSERT INTO tictactoe (game, board)
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<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:
|
the sequence number generated by the <literal>DEFAULT</literal> clause:
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
@@ -751,8 +751,8 @@ INSERT INTO employees_log SELECT *, current_timestamp FROM upd;
|
|||||||
<para>
|
<para>
|
||||||
Insert or update new distributors as appropriate. Assumes a unique
|
Insert or update new distributors as appropriate. Assumes a unique
|
||||||
index has been defined that constrains values appearing in the
|
index has been defined that constrains values appearing in the
|
||||||
<literal>did</literal> column. Note that the special
|
<structfield>did</structfield> column. Note that the special
|
||||||
<varname>excluded</varname> table is used to reference values originally
|
<structname>excluded</structname> table is used to reference values originally
|
||||||
proposed for insertion:
|
proposed for insertion:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
INSERT INTO distributors (did, dname)
|
INSERT INTO distributors (did, dname)
|
||||||
@@ -763,8 +763,8 @@ INSERT INTO distributors (did, dname)
|
|||||||
<para>
|
<para>
|
||||||
Insert or update new distributors as above, returning information
|
Insert or update new distributors as above, returning information
|
||||||
about any existing values that were updated, together with the new data
|
about any existing values that were updated, together with the new data
|
||||||
inserted. Note that the returned values for <literal>old_did</literal>
|
inserted. Note that the returned values for <structfield>old_did</structfield>
|
||||||
and <literal>old_dname</literal> will be <literal>NULL</literal> for
|
and <structfield>old_dname</structfield> will be <literal>NULL</literal> for
|
||||||
non-conflicting rows:
|
non-conflicting rows:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
INSERT INTO distributors (did, dname)
|
INSERT INTO distributors (did, dname)
|
||||||
@@ -779,7 +779,7 @@ INSERT INTO distributors (did, dname)
|
|||||||
when an existing, excluded row (a row with a matching constrained
|
when an existing, excluded row (a row with a matching constrained
|
||||||
column or columns after before row insert triggers fire) exists.
|
column or columns after before row insert triggers fire) exists.
|
||||||
Example assumes a unique index has been defined that constrains
|
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>
|
<programlisting>
|
||||||
INSERT INTO distributors (did, dname) VALUES (7, 'Redline GmbH')
|
INSERT INTO distributors (did, dname) VALUES (7, 'Redline GmbH')
|
||||||
ON CONFLICT (did) DO NOTHING;
|
ON CONFLICT (did) DO NOTHING;
|
||||||
@@ -788,7 +788,7 @@ INSERT INTO distributors (did, dname) VALUES (7, 'Redline GmbH')
|
|||||||
<para>
|
<para>
|
||||||
Insert or update new distributors as appropriate. Example assumes
|
Insert or update new distributors as appropriate. Example assumes
|
||||||
a unique index has been defined that constrains values appearing in
|
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
|
used to limit the rows actually updated (any existing row not
|
||||||
updated will still be locked, though):
|
updated will still be locked, though):
|
||||||
<programlisting>
|
<programlisting>
|
||||||
@@ -808,8 +808,8 @@ INSERT INTO distributors (did, dname) VALUES (9, 'Antwerp Design')
|
|||||||
Insert new distributor if possible; otherwise
|
Insert new distributor if possible; otherwise
|
||||||
<literal>DO NOTHING</literal>. Example assumes a unique index has been
|
<literal>DO NOTHING</literal>. Example assumes a unique index has been
|
||||||
defined that constrains values appearing in the
|
defined that constrains values appearing in the
|
||||||
<literal>did</literal> column on a subset of rows where the
|
<structfield>did</structfield> column on a subset of rows where the
|
||||||
<literal>is_active</literal> Boolean column evaluates to
|
<structfield>is_active</structfield> Boolean column evaluates to
|
||||||
<literal>true</literal>:
|
<literal>true</literal>:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
-- This statement could infer a partial unique index on "did"
|
-- This statement could infer a partial unique index on "did"
|
||||||
|
|||||||
@@ -1878,7 +1878,7 @@ CREATE DATABASE foo WITH TEMPLATE template0;
|
|||||||
|
|
||||||
<para>
|
<para>
|
||||||
To dump all tables whose names start with <literal>mytable</literal>, except
|
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:
|
<filename>filter.txt</filename> like:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
include table mytable*
|
include table mytable*
|
||||||
|
|||||||
@@ -4859,7 +4859,7 @@ bar
|
|||||||
testdb=> <userinput>\set foo 'my_table'</userinput>
|
testdb=> <userinput>\set foo 'my_table'</userinput>
|
||||||
testdb=> <userinput>SELECT * FROM :foo;</userinput>
|
testdb=> <userinput>SELECT * FROM :foo;</userinput>
|
||||||
</programlisting>
|
</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
|
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
|
contain unbalanced quotes, or even backslash commands. You must make sure
|
||||||
that it makes sense where you put it.
|
that it makes sense where you put it.
|
||||||
|
|||||||
@@ -528,7 +528,7 @@ REINDEX INDEX my_index;
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<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>
|
<programlisting>
|
||||||
REINDEX TABLE my_table;
|
REINDEX TABLE my_table;
|
||||||
|
|||||||
@@ -433,7 +433,7 @@ PostgreSQL documentation
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<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>:
|
<literal>bar</literal> in a database named <literal>abcd</literal>:
|
||||||
<screen>
|
<screen>
|
||||||
<prompt>$ </prompt><userinput>reindexdb --table=foo --index=bar abcd</userinput>
|
<prompt>$ </prompt><userinput>reindexdb --table=foo --index=bar abcd</userinput>
|
||||||
|
|||||||
@@ -1768,8 +1768,8 @@ SELECT * FROM <replaceable class="parameter">name</replaceable>
|
|||||||
<title>Examples</title>
|
<title>Examples</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
To join the table <literal>films</literal> with the table
|
To join the table <structname>films</structname> with the table
|
||||||
<literal>distributors</literal>:
|
<structname>distributors</structname>:
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
SELECT f.title, f.did, d.name, f.date_prod, f.kind
|
SELECT f.title, f.did, d.name, f.date_prod, f.kind
|
||||||
@@ -1784,8 +1784,8 @@ SELECT f.title, f.did, d.name, f.date_prod, f.kind
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
To sum the column <literal>len</literal> of all films and group
|
To sum the column <structfield>len</structfield> of all films and group
|
||||||
the results by <literal>kind</literal>:
|
the results by <structfield>kind</structfield>:
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
SELECT kind, sum(len) AS total FROM films GROUP BY kind;
|
SELECT kind, sum(len) AS total FROM films GROUP BY kind;
|
||||||
@@ -1801,8 +1801,8 @@ SELECT kind, sum(len) AS total FROM films GROUP BY kind;
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
To sum the column <literal>len</literal> of all films, group
|
To sum the column <structfield>len</structfield> of all films, group
|
||||||
the results by <literal>kind</literal> and show those group totals
|
the results by <structfield>kind</structfield> and show those group totals
|
||||||
that are less than 5 hours:
|
that are less than 5 hours:
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
@@ -1821,7 +1821,7 @@ SELECT kind, sum(len) AS total
|
|||||||
<para>
|
<para>
|
||||||
The following two examples are identical ways of sorting the individual
|
The following two examples are identical ways of sorting the individual
|
||||||
results according to the contents of the second column
|
results according to the contents of the second column
|
||||||
(<literal>name</literal>):
|
(<structfield>name</structfield>):
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
SELECT * FROM distributors ORDER BY name;
|
SELECT * FROM distributors ORDER BY name;
|
||||||
@@ -1847,8 +1847,8 @@ SELECT * FROM distributors ORDER BY 2;
|
|||||||
|
|
||||||
<para>
|
<para>
|
||||||
The next example shows how to obtain the union of the tables
|
The next example shows how to obtain the union of the tables
|
||||||
<literal>distributors</literal> and
|
<structname>distributors</structname> and
|
||||||
<literal>actors</literal>, restricting the results to those that begin
|
<structname>actors</structname>, restricting the results to those that begin
|
||||||
with the letter W in each table. Only distinct rows are wanted, so the
|
with the letter W in each table. Only distinct rows are wanted, so the
|
||||||
key word <literal>ALL</literal> is omitted.
|
key word <literal>ALL</literal> is omitted.
|
||||||
|
|
||||||
|
|||||||
@@ -120,8 +120,8 @@ SELECT [ ALL | DISTINCT [ ON ( <replaceable class="parameter">expression</replac
|
|||||||
<title>Examples</title>
|
<title>Examples</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Create a new table <literal>films_recent</literal> consisting of only
|
Create a new table <structname>films_recent</structname> consisting of only
|
||||||
recent entries from the table <literal>films</literal>:
|
recent entries from the table <structname>films</structname>:
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
SELECT * INTO films_recent FROM films WHERE date_prod >= '2002-01-01';
|
SELECT * INTO films_recent FROM films WHERE date_prod >= '2002-01-01';
|
||||||
|
|||||||
@@ -182,8 +182,8 @@ TRUNCATE [ TABLE ] [ ONLY ] <replaceable class="parameter">name</replaceable> [
|
|||||||
<title>Examples</title>
|
<title>Examples</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Truncate the tables <literal>bigtable</literal> and
|
Truncate the tables <structname>bigtable</structname> and
|
||||||
<literal>fattable</literal>:
|
<structname>fattable</structname>:
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
TRUNCATE bigtable, fattable;
|
TRUNCATE bigtable, fattable;
|
||||||
@@ -199,8 +199,8 @@ TRUNCATE bigtable, fattable RESTART IDENTITY;
|
|||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Truncate the table <literal>othertable</literal>, and cascade to any tables
|
Truncate the table <structname>othertable</structname>, and cascade to any tables
|
||||||
that reference <literal>othertable</literal> via foreign-key
|
that reference <structname>othertable</structname> via foreign-key
|
||||||
constraints:
|
constraints:
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
|
|||||||
@@ -512,7 +512,7 @@ VACUUM [ ( <replaceable class="parameter">option</replaceable> [, ...] ) ] [ <re
|
|||||||
<title>Examples</title>
|
<title>Examples</title>
|
||||||
|
|
||||||
<para>
|
<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:
|
the optimizer and print a detailed vacuum activity report:
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
|
|||||||
@@ -662,8 +662,8 @@ SELECT shoe_ready.shoename, shoe_ready.sh_avail,
|
|||||||
command other than a <command>SELECT</command>, the result
|
command other than a <command>SELECT</command>, the result
|
||||||
relation points to the range-table entry where the result should
|
relation points to the range-table entry where the result should
|
||||||
go. Everything else is absolutely the same. So having two tables
|
go. Everything else is absolutely the same. So having two tables
|
||||||
<literal>t1</literal> and <literal>t2</literal> with columns <literal>a</literal> and
|
<structname>t1</structname> and <structname>t2</structname> with columns <structfield>a</structfield> and
|
||||||
<literal>b</literal>, the query trees for the two statements:
|
<structfield>b</structfield>, the query trees for the two statements:
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
SELECT t2.b FROM t1, t2 WHERE t1.a = t2.a;
|
SELECT t2.b FROM t1, t2 WHERE t1.a = t2.a;
|
||||||
@@ -676,27 +676,27 @@ UPDATE t1 SET b = t2.b FROM t2 WHERE t1.a = t2.a;
|
|||||||
<itemizedlist>
|
<itemizedlist>
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<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>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<para>
|
||||||
The target lists contain one variable that points to column
|
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>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<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.
|
range-table entries for equality.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>
|
<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>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
@@ -705,7 +705,7 @@ UPDATE t1 SET b = t2.b FROM t2 WHERE t1.a = t2.a;
|
|||||||
<para>
|
<para>
|
||||||
The consequence is, that both query trees result in similar
|
The consequence is, that both query trees result in similar
|
||||||
execution plans: They are both joins over the two tables. For the
|
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
|
the target list by the planner and the final query tree will read
|
||||||
as:
|
as:
|
||||||
|
|
||||||
@@ -727,7 +727,7 @@ SELECT t1.a, t2.b FROM t1, t2 WHERE t1.a = t2.a;
|
|||||||
one is a <command>SELECT</command> command and the other is an
|
one is a <command>SELECT</command> command and the other is an
|
||||||
<command>UPDATE</command> is handled higher up in the executor, where
|
<command>UPDATE</command> is handled higher up in the executor, where
|
||||||
it knows that this is an <command>UPDATE</command>, and it knows that
|
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?
|
that are there has to be replaced by the new row?
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
@@ -739,7 +739,7 @@ SELECT t1.a, t2.b FROM t1, t2 WHERE t1.a = t2.a;
|
|||||||
This is a system column containing the
|
This is a system column containing the
|
||||||
file block number and position in the block for the row. Knowing
|
file block number and position in the block for the row. Knowing
|
||||||
the table, the <acronym>CTID</acronym> can be used to retrieve the
|
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:
|
<acronym>CTID</acronym> to the target list, the query actually looks like:
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
@@ -1691,7 +1691,7 @@ CREATE RULE shoelace_ok_ins AS ON INSERT TO shoelace_ok
|
|||||||
WHERE sl_name = NEW.ok_name;
|
WHERE sl_name = NEW.ok_name;
|
||||||
</programlisting>
|
</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:
|
the data from the parts list:
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
@@ -2355,7 +2355,7 @@ CREATE RULE computer_del AS ON DELETE TO computer
|
|||||||
DELETE FROM computer WHERE hostname = 'mypc.local.net';
|
DELETE FROM computer WHERE hostname = 'mypc.local.net';
|
||||||
</programlisting>
|
</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).
|
command issued by the trigger would also use an index scan (also fast).
|
||||||
The extra command from the rule would be:
|
The extra command from the rule would be:
|
||||||
|
|
||||||
@@ -2421,16 +2421,16 @@ Nestloop
|
|||||||
|
|
||||||
This shows, that the planner does not realize that the
|
This shows, that the planner does not realize that the
|
||||||
qualification for <structfield>hostname</structfield> in
|
qualification for <structfield>hostname</structfield> in
|
||||||
<literal>computer</literal> could also be used for an index scan on
|
<structname>computer</structname> could also be used for an index scan on
|
||||||
<literal>software</literal> when there are multiple qualification
|
<structname>software</structname> when there are multiple qualification
|
||||||
expressions combined with <literal>AND</literal>, which is what it does
|
expressions combined with <literal>AND</literal>, which is what it does
|
||||||
in the regular-expression version of the command. The trigger will
|
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
|
get invoked once for each of the 2000 old computers that have to be
|
||||||
deleted, and that will result in one index scan over
|
deleted, and that will result in one index scan over
|
||||||
<literal>computer</literal> and 2000 index scans over
|
<structname>computer</structname> and 2000 index scans over
|
||||||
<literal>software</literal>. The rule implementation will do it with two
|
<structname>software</structname>. The rule implementation will do it with two
|
||||||
commands that use indexes. And it depends on the overall size of
|
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
|
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.
|
manager take some time, even if all the index blocks will soon be in the cache.
|
||||||
</para>
|
</para>
|
||||||
@@ -2443,7 +2443,7 @@ DELETE FROM computer WHERE manufacturer = 'bim';
|
|||||||
</programlisting>
|
</programlisting>
|
||||||
|
|
||||||
Again this could result in many rows to be deleted from
|
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:
|
through the executor. The command generated by the rule will be:
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
@@ -2452,7 +2452,7 @@ DELETE FROM software WHERE computer.manufacturer = 'bim'
|
|||||||
</programlisting>
|
</programlisting>
|
||||||
|
|
||||||
The plan for that command will again be the nested loop over two
|
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>
|
<programlisting>
|
||||||
Nestloop
|
Nestloop
|
||||||
|
|||||||
@@ -2430,8 +2430,8 @@ SELECT ROW(1,2.5,'this is a test');
|
|||||||
which will be expanded to a list of the elements of the row value,
|
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
|
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"/>).
|
of a <command>SELECT</command> list (see <xref linkend="rowtypes-usage"/>).
|
||||||
For example, if table <literal>t</literal> has
|
For example, if table <structname>t</structname> has
|
||||||
columns <literal>f1</literal> and <literal>f2</literal>, these are the same:
|
columns <structfield>f1</structfield> and <structfield>f2</structfield>, these are the same:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
SELECT ROW(t.*, 42) FROM t;
|
SELECT ROW(t.*, 42) FROM t;
|
||||||
SELECT ROW(t.f1, t.f2, 42) FROM t;
|
SELECT ROW(t.f1, t.f2, 42) FROM t;
|
||||||
|
|||||||
@@ -397,8 +397,8 @@ SELECT tf1(17, 100.0);
|
|||||||
<para>
|
<para>
|
||||||
In this example, we chose the name <literal>accountno</literal> for the first
|
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
|
argument, but this is the same as the name of a column in the
|
||||||
<literal>bank</literal> table. Within the <command>UPDATE</command> command,
|
<structname>bank</structname> table. Within the <command>UPDATE</command> command,
|
||||||
<literal>accountno</literal> refers to the column <literal>bank.accountno</literal>,
|
<literal>accountno</literal> refers to the column <structfield>bank.accountno</structfield>,
|
||||||
so <literal>tf1.accountno</literal> must be used to refer to the argument.
|
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.
|
We could of course avoid this by using a different name for the argument.
|
||||||
</para>
|
</para>
|
||||||
@@ -1016,7 +1016,7 @@ SELECT *, upper(fooname) FROM getfoo(1) AS t1;
|
|||||||
This feature is normally used when calling the function in the <literal>FROM</literal>
|
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
|
clause. In this case each row returned by the function becomes
|
||||||
a row of the table seen by the query. For example, assume that
|
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>
|
<programlisting>
|
||||||
CREATE FUNCTION getfoo(int) RETURNS SETOF foo AS $$
|
CREATE FUNCTION getfoo(int) RETURNS SETOF foo AS $$
|
||||||
|
|||||||
Reference in New Issue
Block a user