database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-11-13 16:22:44 +03:00
Code Activity

doc: consistently use "structname" and "structfield" markup

Browse Source 
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:
Bruce Momjian
2025-11-08 09:49:43 -05:00
parent e8bfad4ca8
commit 980a855c5c
33 changed files with 166 additions and 166 deletions
Download Patch File Download Diff File Expand all files Collapse all files

26
doc/src/sgml/advanced.sgml
View File

@@ -80,18 +80,18 @@ SELECT * FROM myview;
</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>
@@ -578,8 +578,8 @@ SELECT sum(salary) OVER w, avg(salary) OVER w
</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:
@@ -625,14 +625,14 @@ CREATE TABLE capitals (
</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
@@ -685,8 +685,8 @@ SELECT name, elevation
<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 &mdash;
<command>SELECT</command>, <command>UPDATE</command>, and
<command>DELETE</command> &mdash; support this <literal>ONLY</literal>

6
doc/src/sgml/ddl.sgml
View File

@@ -1353,7 +1353,7 @@ CREATE TABLE posts (
);
</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>
@@ -2831,7 +2831,7 @@ REVOKE ALL ON accounts FROM PUBLIC;
<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;
@@ -3059,7 +3059,7 @@ CREATE POLICY user_mod_policy ON users
<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>

2
doc/src/sgml/ecpg.sgml
View File

@@ -1827,7 +1827,7 @@ while (1)
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>

4
doc/src/sgml/func/func-json.sgml
View File

@@ -3899,8 +3899,8 @@ SELECT jt.* FROM
<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 (

32
doc/src/sgml/indices.sgml
View File

@@ -593,7 +593,7 @@ CREATE INDEX test2_mm_idx ON test2 (major, minor);
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>
@@ -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
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
@@ -1179,9 +1179,9 @@ CREATE INDEX mytable_cat_data ON mytable (category, data);
<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 &lt; 42;
@@ -1262,15 +1262,15 @@ CREATE INDEX tab_x_y ON tab(x) INCLUDE (y);
</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
@@ -1300,7 +1300,7 @@ CREATE UNIQUE INDEX tab_x_y ON tab(x) INCLUDE (y);
<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"/>.
@@ -1340,7 +1340,7 @@ SELECT f(x) FROM tab WHERE f(x) &lt; 1;
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>

36
doc/src/sgml/information_schema.sgml
View File

@@ -2089,15 +2089,15 @@
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
@@ -2107,8 +2107,8 @@
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.
@@ -6376,7 +6376,7 @@ ORDER BY c.ordinal_position;
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>
@@ -6386,8 +6386,8 @@ ORDER BY c.ordinal_position;
</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>
@@ -6402,7 +6402,7 @@ ORDER BY c.ordinal_position;
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>
@@ -6461,10 +6461,10 @@ ORDER BY c.ordinal_position;
</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"/>.
@@ -6556,10 +6556,10 @@ ORDER BY c.ordinal_position;
</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;
@@ -6638,10 +6638,10 @@ ORDER BY c.ordinal_position;
</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>
@@ -6714,10 +6714,10 @@ ORDER BY c.ordinal_position;
</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;
@@ -7843,7 +7843,7 @@ ORDER BY c.ordinal_position;
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,

4
doc/src/sgml/libpq.sgml
View File

@@ -4508,7 +4508,7 @@ Oid PQftable(const PGresult *res,
<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>
@@ -4578,7 +4578,7 @@ Oid PQftype(const PGresult *res,
</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>

26
doc/src/sgml/logical-replication.sgml
View File

@@ -439,7 +439,7 @@
<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;
@@ -1036,8 +1036,8 @@ HINT: To initiate replication, you must manually create the replication slot, e
<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');
@@ -1076,9 +1076,9 @@ Tables:
<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
@@ -1121,7 +1121,7 @@ Publications:
]]></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>
@@ -1474,14 +1474,14 @@ Publications:
<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>
@@ -1522,9 +1522,9 @@ Publications:
</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>
@@ -1535,7 +1535,7 @@ Publications:
</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');
@@ -3285,8 +3285,8 @@ CREATE SUBSCRIPTION mysub CONNECTION 'dbname=foo host=bar user=repuser' PUBLICAT
<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>

8
doc/src/sgml/plperl.sgml
View File

@@ -468,8 +468,8 @@ optional maximum number of rows:
$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-&gt;{rows}[$i]-&gt;{my_column};
@@ -1199,7 +1199,7 @@ $$ LANGUAGE plperl;
<term><literal>$_TD-&gt;{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>
@@ -1208,7 +1208,7 @@ $$ LANGUAGE plperl;
<term><literal>$_TD-&gt;{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>

6
doc/src/sgml/queries.sgml
View File

@@ -410,7 +410,7 @@ FROM <replaceable>table_reference</replaceable> <optional>, <replaceable>table_r
</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
-----+------
@@ -418,7 +418,7 @@ FROM <replaceable>table_reference</replaceable> <optional>, <replaceable>table_r
2 | b
3 | c
</programlisting>
and <literal>t2</literal>:
and <structname>t2</structname>:
<programlisting>
num | value
-----+-------
@@ -1079,7 +1079,7 @@ SELECT <replaceable>select_list</replaceable>
<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>

4
doc/src/sgml/ref/cluster.sgml
View File

@@ -220,7 +220,7 @@ CLUSTER [ ( <replaceable class="parameter">option</replaceable> [, ...] ) ] [ <r
<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;
@@ -228,7 +228,7 @@ 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;

2
doc/src/sgml/ref/comment.sgml
View File

@@ -301,7 +301,7 @@ COMMENT ON
<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.';

2
doc/src/sgml/ref/create_foreign_table.sgml
View File

@@ -360,7 +360,7 @@ WITH ( MODULUS <replaceable class="parameter">numeric_literal</replaceable>, REM
<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>

4
doc/src/sgml/ref/create_function.sgml
View File

@@ -817,10 +817,10 @@ $$ LANGUAGE plpgsql
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>

14
doc/src/sgml/ref/create_index.sgml
View File

@@ -898,17 +898,17 @@ Indexes:
<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>
@@ -960,8 +960,8 @@ CREATE INDEX gin_idx ON documents_table USING GIN (locations) WITH (fastupdate =
</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;

2
doc/src/sgml/ref/create_table.sgml
View File

@@ -862,7 +862,7 @@ WITH ( MODULUS <replaceable class="parameter">numeric_literal</replaceable>, REM
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>

8
doc/src/sgml/ref/create_table_as.sgml
View File

@@ -266,8 +266,8 @@ CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } | UNLOGGED ] TABLE [ IF NOT EXI
<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
@@ -286,8 +286,8 @@ CREATE TABLE films2 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>

10
doc/src/sgml/ref/create_trigger.sgml
View File

@@ -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
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>
@@ -598,7 +598,7 @@ UPDATE OF <replaceable>column_name1</replaceable> [, <replaceable>column_name2</
<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
@@ -608,7 +608,7 @@ 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>
@@ -618,7 +618,7 @@ CREATE OR REPLACE TRIGGER check_update
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>
@@ -629,7 +629,7 @@ CREATE TRIGGER check_update
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>

16
doc/src/sgml/ref/create_view.sgml
View File

@@ -492,7 +492,7 @@ CREATE VIEW comedies AS
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>
@@ -507,12 +507,12 @@ CREATE VIEW universal_comedies AS
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>
@@ -525,8 +525,8 @@ CREATE VIEW pg_comedies AS
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>
@@ -543,9 +543,9 @@ CREATE VIEW comedies AS
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>

2
doc/src/sgml/ref/delete.sgml
View File

@@ -285,7 +285,7 @@ DELETE FROM films WHERE kind &lt;&gt; 'Musical';
</para>
<para>
Clear the table <literal>films</literal>:
Clear the table <structname>films</structname>:
<programlisting>
DELETE FROM films;
</programlisting>

6
doc/src/sgml/ref/grant.sgml
View File

@@ -434,7 +434,7 @@ GRANT <replaceable class="parameter">role_name</replaceable> [, ...] TO <replace
<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;
@@ -443,14 +443,14 @@ 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>

26
doc/src/sgml/ref/insert.sgml
View File

@@ -654,7 +654,7 @@ INSERT <replaceable>oid</replaceable> <replaceable class="parameter">count</repl
<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
@@ -663,7 +663,7 @@ 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>
@@ -704,8 +704,8 @@ INSERT INTO films (code, title, did, date_prod, kind) VALUES
<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 &lt; '2004-05-07';
@@ -726,7 +726,7 @@ INSERT INTO tictactoe (game, board)
</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>
@@ -751,8 +751,8 @@ INSERT INTO employees_log SELECT *, current_timestamp FROM upd;
<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)
@@ -763,8 +763,8 @@ 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)
@@ -779,7 +779,7 @@ 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;
@@ -788,7 +788,7 @@ INSERT INTO distributors (did, dname) VALUES (7, 'Redline GmbH')
<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>
@@ -808,8 +808,8 @@ INSERT INTO distributors (did, dname) VALUES (9, 'Antwerp Design')
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"

2
doc/src/sgml/ref/pg_dump.sgml
View File

@@ -1878,7 +1878,7 @@ CREATE DATABASE foo WITH TEMPLATE template0;
<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*

2
doc/src/sgml/ref/psql-ref.sgml
View File

@@ -4859,7 +4859,7 @@ bar
testdb=&gt; <userinput>\set foo 'my_table'</userinput>
testdb=&gt; <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.

2
doc/src/sgml/ref/reindex.sgml
View File

@@ -528,7 +528,7 @@ REINDEX INDEX my_index;
</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;

2
doc/src/sgml/ref/reindexdb.sgml
View File

@@ -433,7 +433,7 @@ PostgreSQL documentation
</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>

18
doc/src/sgml/ref/select.sgml
View File

@@ -1768,8 +1768,8 @@ SELECT * FROM <replaceable class="parameter">name</replaceable>
<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
@@ -1784,8 +1784,8 @@ 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;
@@ -1801,8 +1801,8 @@ 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>
@@ -1821,7 +1821,7 @@ SELECT kind, sum(len) AS total
<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;
@@ -1847,8 +1847,8 @@ SELECT * FROM distributors ORDER BY 2;
<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.

4
doc/src/sgml/ref/select_into.sgml
View File

@@ -120,8 +120,8 @@ SELECT [ ALL | DISTINCT [ ON ( <replaceable class="parameter">expression</replac
<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 &gt;= '2002-01-01';

8
doc/src/sgml/ref/truncate.sgml
View File

@@ -182,8 +182,8 @@ TRUNCATE [ TABLE ] [ ONLY ] <replaceable class="parameter">name</replaceable> [
<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;
@@ -199,8 +199,8 @@ TRUNCATE bigtable, fattable RESTART IDENTITY;
</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>

2
doc/src/sgml/ref/vacuum.sgml
View File

@@ -512,7 +512,7 @@ VACUUM [ ( <replaceable class="parameter">option</replaceable> [, ...] ) ] [ <re
<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>

36
doc/src/sgml/rules.sgml
View File

@@ -662,8 +662,8 @@ SELECT shoe_ready.shoename, shoe_ready.sh_avail,
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;
@@ -676,27 +676,27 @@ UPDATE t1 SET b = t2.b FROM 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>
@@ -705,7 +705,7 @@ UPDATE t1 SET b = t2.b FROM t2 WHERE t1.a = t2.a;
<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:
@@ -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
<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>
@@ -739,7 +739,7 @@ SELECT t1.a, t2.b FROM t1, t2 WHERE t1.a = t2.a;
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>
@@ -1691,7 +1691,7 @@ CREATE RULE shoelace_ok_ins AS ON INSERT TO shoelace_ok
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>
@@ -2355,7 +2355,7 @@ CREATE RULE computer_del AS ON DELETE TO computer
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:
@@ -2421,16 +2421,16 @@ Nestloop
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>
@@ -2443,7 +2443,7 @@ DELETE FROM computer WHERE manufacturer = 'bim';
</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>
@@ -2452,7 +2452,7 @@ DELETE FROM software WHERE computer.manufacturer = 'bim'
</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

4
doc/src/sgml/syntax.sgml
View File

@@ -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,
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;

6
doc/src/sgml/xfunc.sgml
View File

@@ -397,8 +397,8 @@ SELECT tf1(17, 100.0);
<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>
@@ -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>
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 $$