diff options
Diffstat (limited to 'doc/src')
33 files changed, 166 insertions, 166 deletions
diff --git a/doc/src/sgml/advanced.sgml b/doc/src/sgml/advanced.sgml index 82e82c13457..451bcb202ec 100644 --- a/doc/src/sgml/advanced.sgml +++ b/doc/src/sgml/advanced.sgml @@ -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 — <command>SELECT</command>, <command>UPDATE</command>, and <command>DELETE</command> — support this <literal>ONLY</literal> diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml index 3e5fb590593..948b9327f24 100644 --- a/doc/src/sgml/ddl.sgml +++ b/doc/src/sgml/ddl.sgml @@ -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> diff --git a/doc/src/sgml/ecpg.sgml b/doc/src/sgml/ecpg.sgml index df3965ec93f..807dadcb4a3 100644 --- a/doc/src/sgml/ecpg.sgml +++ b/doc/src/sgml/ecpg.sgml @@ -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> diff --git a/doc/src/sgml/func/func-json.sgml b/doc/src/sgml/func/func-json.sgml index c529ddf1808..1ec73cff464 100644 --- a/doc/src/sgml/func/func-json.sgml +++ b/doc/src/sgml/func/func-json.sgml @@ -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 ( diff --git a/doc/src/sgml/indices.sgml b/doc/src/sgml/indices.sgml index 6469f032f23..55f39b0df2f 100644 --- a/doc/src/sgml/indices.sgml +++ b/doc/src/sgml/indices.sgml @@ -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 < 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) < 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> diff --git a/doc/src/sgml/information_schema.sgml b/doc/src/sgml/information_schema.sgml index 19dffe7be6a..60b4c4ae8c0 100644 --- a/doc/src/sgml/information_schema.sgml +++ b/doc/src/sgml/information_schema.sgml @@ -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, diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml index 1c5ae9ad08f..7ab679a765d 100644 --- a/doc/src/sgml/libpq.sgml +++ b/doc/src/sgml/libpq.sgml @@ -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> diff --git a/doc/src/sgml/logical-replication.sgml b/doc/src/sgml/logical-replication.sgml index daab2cae989..d64ed9dc36b 100644 --- a/doc/src/sgml/logical-replication.sgml +++ b/doc/src/sgml/logical-replication.sgml @@ -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> diff --git a/doc/src/sgml/plperl.sgml b/doc/src/sgml/plperl.sgml index 011b9792325..6f018645f11 100644 --- a/doc/src/sgml/plperl.sgml +++ b/doc/src/sgml/plperl.sgml @@ -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->{rows}[$i]->{my_column}; @@ -1199,7 +1199,7 @@ $$ LANGUAGE plperl; <term><literal>$_TD->{new}{foo}</literal></term> <listitem> <para> - <literal>NEW</literal> value of column <literal>foo</literal> + <literal>NEW</literal> value of column <structfield>foo</structfield> </para> </listitem> </varlistentry> @@ -1208,7 +1208,7 @@ $$ LANGUAGE plperl; <term><literal>$_TD->{old}{foo}</literal></term> <listitem> <para> - <literal>OLD</literal> value of column <literal>foo</literal> + <literal>OLD</literal> value of column <structfield>foo</structfield> </para> </listitem> </varlistentry> diff --git a/doc/src/sgml/queries.sgml b/doc/src/sgml/queries.sgml index 8d5ba72a198..4b522213171 100644 --- a/doc/src/sgml/queries.sgml +++ b/doc/src/sgml/queries.sgml @@ -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> diff --git a/doc/src/sgml/ref/cluster.sgml b/doc/src/sgml/ref/cluster.sgml index 8811f169ea0..0b47460080b 100644 --- a/doc/src/sgml/ref/cluster.sgml +++ b/doc/src/sgml/ref/cluster.sgml @@ -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; diff --git a/doc/src/sgml/ref/comment.sgml b/doc/src/sgml/ref/comment.sgml index 5b43c56b133..8d81244910b 100644 --- a/doc/src/sgml/ref/comment.sgml +++ b/doc/src/sgml/ref/comment.sgml @@ -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.'; diff --git a/doc/src/sgml/ref/create_foreign_table.sgml b/doc/src/sgml/ref/create_foreign_table.sgml index 009fa46532b..08a8ceeae75 100644 --- a/doc/src/sgml/ref/create_foreign_table.sgml +++ b/doc/src/sgml/ref/create_foreign_table.sgml @@ -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> diff --git a/doc/src/sgml/ref/create_function.sgml b/doc/src/sgml/ref/create_function.sgml index e748e842353..30bd4602f8d 100644 --- a/doc/src/sgml/ref/create_function.sgml +++ b/doc/src/sgml/ref/create_function.sgml @@ -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> diff --git a/doc/src/sgml/ref/create_index.sgml b/doc/src/sgml/ref/create_index.sgml index b9c679c41e8..bb7505d171b 100644 --- a/doc/src/sgml/ref/create_index.sgml +++ b/doc/src/sgml/ref/create_index.sgml @@ -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; diff --git a/doc/src/sgml/ref/create_table.sgml b/doc/src/sgml/ref/create_table.sgml index 94093599ca2..6557c5cffd8 100644 --- a/doc/src/sgml/ref/create_table.sgml +++ b/doc/src/sgml/ref/create_table.sgml @@ -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> diff --git a/doc/src/sgml/ref/create_table_as.sgml b/doc/src/sgml/ref/create_table_as.sgml index 8429333e3af..6b41226cbd6 100644 --- a/doc/src/sgml/ref/create_table_as.sgml +++ b/doc/src/sgml/ref/create_table_as.sgml @@ -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> diff --git a/doc/src/sgml/ref/create_trigger.sgml b/doc/src/sgml/ref/create_trigger.sgml index 0d8d463479b..bb1426f4970 100644 --- a/doc/src/sgml/ref/create_trigger.sgml +++ b/doc/src/sgml/ref/create_trigger.sgml @@ -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> diff --git a/doc/src/sgml/ref/create_view.sgml b/doc/src/sgml/ref/create_view.sgml index e8d9d3c8d0f..7b6b750c6de 100644 --- a/doc/src/sgml/ref/create_view.sgml +++ b/doc/src/sgml/ref/create_view.sgml @@ -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> diff --git a/doc/src/sgml/ref/delete.sgml b/doc/src/sgml/ref/delete.sgml index 29649f6afd6..5b52f77e28f 100644 --- a/doc/src/sgml/ref/delete.sgml +++ b/doc/src/sgml/ref/delete.sgml @@ -285,7 +285,7 @@ DELETE FROM films WHERE kind <> 'Musical'; </para> <para> - Clear the table <literal>films</literal>: + Clear the table <structname>films</structname>: <programlisting> DELETE FROM films; </programlisting> diff --git a/doc/src/sgml/ref/grant.sgml b/doc/src/sgml/ref/grant.sgml index 999f657d5c0..043f5d5a40a 100644 --- a/doc/src/sgml/ref/grant.sgml +++ b/doc/src/sgml/ref/grant.sgml @@ -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> diff --git a/doc/src/sgml/ref/insert.sgml b/doc/src/sgml/ref/insert.sgml index b337f2ee555..0598b8dea34 100644 --- a/doc/src/sgml/ref/insert.sgml +++ b/doc/src/sgml/ref/insert.sgml @@ -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 < '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" diff --git a/doc/src/sgml/ref/pg_dump.sgml b/doc/src/sgml/ref/pg_dump.sgml index 5ac3f3e8510..ae7718e1a93 100644 --- a/doc/src/sgml/ref/pg_dump.sgml +++ b/doc/src/sgml/ref/pg_dump.sgml @@ -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* diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml index 1ab427d18af..f56c70263e0 100644 --- a/doc/src/sgml/ref/psql-ref.sgml +++ b/doc/src/sgml/ref/psql-ref.sgml @@ -4859,7 +4859,7 @@ bar testdb=> <userinput>\set foo 'my_table'</userinput> testdb=> <userinput>SELECT * FROM :foo;</userinput> </programlisting> - would query the table <literal>my_table</literal>. Note that this + would query the table <structname>my_table</structname>. Note that this may be unsafe: the value of the variable is copied literally, so it can contain unbalanced quotes, or even backslash commands. You must make sure that it makes sense where you put it. diff --git a/doc/src/sgml/ref/reindex.sgml b/doc/src/sgml/ref/reindex.sgml index c4055397146..185cd75ca30 100644 --- a/doc/src/sgml/ref/reindex.sgml +++ b/doc/src/sgml/ref/reindex.sgml @@ -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; diff --git a/doc/src/sgml/ref/reindexdb.sgml b/doc/src/sgml/ref/reindexdb.sgml index abcb041179b..a90e48ea86b 100644 --- a/doc/src/sgml/ref/reindexdb.sgml +++ b/doc/src/sgml/ref/reindexdb.sgml @@ -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> diff --git a/doc/src/sgml/ref/select.sgml b/doc/src/sgml/ref/select.sgml index fd441ef4487..ca5dd14d627 100644 --- a/doc/src/sgml/ref/select.sgml +++ b/doc/src/sgml/ref/select.sgml @@ -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. diff --git a/doc/src/sgml/ref/select_into.sgml b/doc/src/sgml/ref/select_into.sgml index 233f9bfa284..cbf865ff838 100644 --- a/doc/src/sgml/ref/select_into.sgml +++ b/doc/src/sgml/ref/select_into.sgml @@ -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 >= '2002-01-01'; diff --git a/doc/src/sgml/ref/truncate.sgml b/doc/src/sgml/ref/truncate.sgml index 9d846f88c9f..d6efa286e99 100644 --- a/doc/src/sgml/ref/truncate.sgml +++ b/doc/src/sgml/ref/truncate.sgml @@ -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> diff --git a/doc/src/sgml/ref/vacuum.sgml b/doc/src/sgml/ref/vacuum.sgml index bd5dcaf86a5..6d0fdd43cfb 100644 --- a/doc/src/sgml/ref/vacuum.sgml +++ b/doc/src/sgml/ref/vacuum.sgml @@ -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> diff --git a/doc/src/sgml/rules.sgml b/doc/src/sgml/rules.sgml index 50ac9bd4bdb..7f23962f524 100644 --- a/doc/src/sgml/rules.sgml +++ b/doc/src/sgml/rules.sgml @@ -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 diff --git a/doc/src/sgml/syntax.sgml b/doc/src/sgml/syntax.sgml index 237d7306fe8..34c83880a66 100644 --- a/doc/src/sgml/syntax.sgml +++ b/doc/src/sgml/syntax.sgml @@ -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; diff --git a/doc/src/sgml/xfunc.sgml b/doc/src/sgml/xfunc.sgml index cdc387805b1..7dcd7d32329 100644 --- a/doc/src/sgml/xfunc.sgml +++ b/doc/src/sgml/xfunc.sgml @@ -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 $$ |