Commit 1c53f612 authored by Peter Eisentraut's avatar Peter Eisentraut

Escape < and & in SGML

This is not required in SGML, but will be in XML, so this is a step to
prepare for the conversion to XML.  (It is still not required to escape
>, but we did it here in some cases for symmetry.)

Add a command-line option to osx/onsgmls calls to warn about unescaped
occurrences in the future.

Author: Alexander Law <exclusion@gmail.com>
Author: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
parent 8689e382
...@@ -66,10 +66,13 @@ ALLSGML := $(wildcard $(srcdir)/*.sgml $(srcdir)/ref/*.sgml) $(GENERATED_SGML) ...@@ -66,10 +66,13 @@ ALLSGML := $(wildcard $(srcdir)/*.sgml $(srcdir)/ref/*.sgml) $(GENERATED_SGML)
# Enable some extra warnings # Enable some extra warnings
# -wfully-tagged needed to throw a warning on missing tags # -wfully-tagged needed to throw a warning on missing tags
# for older tool chains, 2007-08-31 # for older tool chains, 2007-08-31
# Note: try "make SPFLAGS=-wxml" to catch a lot of other dubious constructs,
# in particular < and & that haven't been made into entities. It's far too
# noisy to turn on by default, unfortunately.
override SPFLAGS += -wall -wno-unused-param -wno-empty -wfully-tagged override SPFLAGS += -wall -wno-unused-param -wno-empty -wfully-tagged
# Additional warnings for XML compatibility. The conditional is meant
# to detect whether we are using OpenSP rather than the ancient
# original SP.
ifneq (,$(filter o%,$(notdir $(OSX))))
override SPFLAGS += -wdata-delim
endif
## ##
......
...@@ -654,7 +654,7 @@ SELECT * FROM ...@@ -654,7 +654,7 @@ SELECT * FROM
For instance: For instance:
<programlisting> <programlisting>
SELECT * FROM sal_emp WHERE pay_by_quarter && ARRAY[10000]; SELECT * FROM sal_emp WHERE pay_by_quarter &amp;&amp; ARRAY[10000];
</programlisting> </programlisting>
This and other array operators are further described in This and other array operators are further described in
......
...@@ -696,9 +696,9 @@ IsForeignRelUpdatable (Relation rel); ...@@ -696,9 +696,9 @@ IsForeignRelUpdatable (Relation rel);
The return value should be a bit mask of rule event numbers indicating The return value should be a bit mask of rule event numbers indicating
which operations are supported by the foreign table, using the which operations are supported by the foreign table, using the
<literal>CmdType</> enumeration; that is, <literal>CmdType</> enumeration; that is,
<literal>(1 << CMD_UPDATE) = 4</> for <command>UPDATE</>, <literal>(1 &lt;&lt; CMD_UPDATE) = 4</> for <command>UPDATE</>,
<literal>(1 << CMD_INSERT) = 8</> for <command>INSERT</>, and <literal>(1 &lt;&lt; CMD_INSERT) = 8</> for <command>INSERT</>, and
<literal>(1 << CMD_DELETE) = 16</> for <command>DELETE</>. <literal>(1 &lt;&lt; CMD_DELETE) = 16</> for <command>DELETE</>.
</para> </para>
<para> <para>
......
...@@ -1823,8 +1823,8 @@ $BODY$ ...@@ -1823,8 +1823,8 @@ $BODY$
BEGIN BEGIN
RETURN QUERY SELECT flightid RETURN QUERY SELECT flightid
FROM flight FROM flight
WHERE flightdate >= $1 WHERE flightdate &gt;= $1
AND flightdate < ($1 + 1); AND flightdate &lt; ($1 + 1);
-- Since execution is not finished, we can check whether rows were returned -- Since execution is not finished, we can check whether rows were returned
-- and raise exception if not. -- and raise exception if not.
......
...@@ -134,9 +134,9 @@ ALTER OPERATOR @@ (text, text) OWNER TO joe; ...@@ -134,9 +134,9 @@ ALTER OPERATOR @@ (text, text) OWNER TO joe;
</programlisting></para> </programlisting></para>
<para> <para>
Change the restriction and join selectivity estimator functions of a custom operator <literal>a && b</literal> for type <type>int[]</type>: Change the restriction and join selectivity estimator functions of a custom operator <literal>a &amp;&amp; b</literal> for type <type>int[]</type>:
<programlisting> <programlisting>
ALTER OPERATOR && (_int4, _int4) SET (RESTRICT = _int_contsel, JOIN = _int_contjoinsel); ALTER OPERATOR &amp;&amp; (_int4, _int4) SET (RESTRICT = _int_contsel, JOIN = _int_contjoinsel);
</programlisting></para> </programlisting></para>
</refsect1> </refsect1>
......
...@@ -466,7 +466,7 @@ CREATE VIEW comedies AS ...@@ -466,7 +466,7 @@ CREATE VIEW comedies AS
CREATE RECURSIVE VIEW public.nums_1_100 (n) AS CREATE RECURSIVE VIEW public.nums_1_100 (n) AS
VALUES (1) VALUES (1)
UNION ALL UNION ALL
SELECT n+1 FROM nums_1_100 WHERE n < 100; SELECT n+1 FROM nums_1_100 WHERE n &lt; 100;
</programlisting> </programlisting>
Notice that although the recursive view's name is schema-qualified in this Notice that although the recursive view's name is schema-qualified in this
<command>CREATE</>, its internal self-reference is not schema-qualified. <command>CREATE</>, its internal self-reference is not schema-qualified.
......
...@@ -94,7 +94,7 @@ ...@@ -94,7 +94,7 @@
nanoseconds. This example from an Intel i7-860 system using a TSC clock nanoseconds. This example from an Intel i7-860 system using a TSC clock
source shows excellent performance: source shows excellent performance:
<screen> <screen><![CDATA[
Testing timing overhead for 3 seconds. Testing timing overhead for 3 seconds.
Per loop time including overhead: 35.96 ns Per loop time including overhead: 35.96 ns
Histogram of timing durations: Histogram of timing durations:
...@@ -104,7 +104,7 @@ Histogram of timing durations: ...@@ -104,7 +104,7 @@ Histogram of timing durations:
4 0.00015 126 4 0.00015 126
8 0.00002 13 8 0.00002 13
16 0.00000 2 16 0.00000 2
</screen> ]]></screen>
</para> </para>
<para> <para>
...@@ -152,7 +152,7 @@ EXPLAIN ANALYZE SELECT COUNT(*) FROM t; ...@@ -152,7 +152,7 @@ EXPLAIN ANALYZE SELECT COUNT(*) FROM t;
possible from switching to the slower acpi_pm time source, on the same possible from switching to the slower acpi_pm time source, on the same
system used for the fast results above: system used for the fast results above:
<screen> <screen><![CDATA[
# cat /sys/devices/system/clocksource/clocksource0/available_clocksource # cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet acpi_pm tsc hpet acpi_pm
# echo acpi_pm > /sys/devices/system/clocksource/clocksource0/current_clocksource # echo acpi_pm > /sys/devices/system/clocksource/clocksource0/current_clocksource
...@@ -165,7 +165,7 @@ Histogram of timing durations: ...@@ -165,7 +165,7 @@ Histogram of timing durations:
4 0.07810 3241 4 0.07810 3241
8 0.01357 563 8 0.01357 563
16 0.00007 3 16 0.00007 3
</screen> ]]></screen>
</para> </para>
<para> <para>
...@@ -201,7 +201,7 @@ kern.timecounter.hardware: ACPI-fast -> TSC ...@@ -201,7 +201,7 @@ kern.timecounter.hardware: ACPI-fast -> TSC
implementation, which can have good resolution when it's backed by fast implementation, which can have good resolution when it's backed by fast
enough timing hardware, as in this example: enough timing hardware, as in this example:
<screen> <screen><![CDATA[
$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource $ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
jiffies jiffies
$ dmesg | grep time.c $ dmesg | grep time.c
...@@ -218,7 +218,7 @@ Histogram of timing durations: ...@@ -218,7 +218,7 @@ Histogram of timing durations:
8 0.00007 22 8 0.00007 22
16 0.00000 1 16 0.00000 1
32 0.00000 1 32 0.00000 1
</screen></para> ]]></screen></para>
</refsect2> </refsect2>
......
...@@ -962,7 +962,7 @@ ...@@ -962,7 +962,7 @@
to fix all pre-existing data errors. However, an installation can be to fix all pre-existing data errors. However, an installation can be
presumed safe after performing this vacuuming if it has executed fewer presumed safe after performing this vacuuming if it has executed fewer
than 2^31 update transactions in its lifetime (check this with than 2^31 update transactions in its lifetime (check this with
<literal>SELECT txid_current() < 2^31</>). <literal>SELECT txid_current() &lt; 2^31</>).
</para> </para>
</listitem> </listitem>
......
...@@ -2900,7 +2900,7 @@ ...@@ -2900,7 +2900,7 @@
to fix all pre-existing data errors. However, an installation can be to fix all pre-existing data errors. However, an installation can be
presumed safe after performing this vacuuming if it has executed fewer presumed safe after performing this vacuuming if it has executed fewer
than 2^31 update transactions in its lifetime (check this with than 2^31 update transactions in its lifetime (check this with
<literal>SELECT txid_current() < 2^31</>). <literal>SELECT txid_current() &lt; 2^31</>).
</para> </para>
</listitem> </listitem>
......
...@@ -4654,7 +4654,7 @@ Branch: REL9_0_STABLE [9d6af7367] 2015-08-15 11:02:34 -0400 ...@@ -4654,7 +4654,7 @@ Branch: REL9_0_STABLE [9d6af7367] 2015-08-15 11:02:34 -0400
to fix all pre-existing data errors. However, an installation can be to fix all pre-existing data errors. However, an installation can be
presumed safe after performing this vacuuming if it has executed fewer presumed safe after performing this vacuuming if it has executed fewer
than 2^31 update transactions in its lifetime (check this with than 2^31 update transactions in its lifetime (check this with
<literal>SELECT txid_current() < 2^31</>). <literal>SELECT txid_current() &lt; 2^31</>).
</para> </para>
</listitem> </listitem>
......
...@@ -6553,7 +6553,7 @@ Branch: REL9_2_STABLE [6b700301c] 2015-02-17 16:03:00 +0100 ...@@ -6553,7 +6553,7 @@ Branch: REL9_2_STABLE [6b700301c] 2015-02-17 16:03:00 +0100
to fix all pre-existing data errors. However, an installation can be to fix all pre-existing data errors. However, an installation can be
presumed safe after performing this vacuuming if it has executed fewer presumed safe after performing this vacuuming if it has executed fewer
than 2^31 update transactions in its lifetime (check this with than 2^31 update transactions in its lifetime (check this with
<literal>SELECT txid_current() < 2^31</>). <literal>SELECT txid_current() &lt; 2^31</>).
</para> </para>
</listitem> </listitem>
......
...@@ -9930,7 +9930,7 @@ Branch: REL8_4_STABLE [c0c2d62ac] 2014-02-14 21:59:56 -0500 ...@@ -9930,7 +9930,7 @@ Branch: REL8_4_STABLE [c0c2d62ac] 2014-02-14 21:59:56 -0500
to fix all pre-existing data errors. However, an installation can be to fix all pre-existing data errors. However, an installation can be
presumed safe after performing this vacuuming if it has executed fewer presumed safe after performing this vacuuming if it has executed fewer
than 2^31 update transactions in its lifetime (check this with than 2^31 update transactions in its lifetime (check this with
<literal>SELECT txid_current() < 2^31</>). <literal>SELECT txid_current() &lt; 2^31</>).
</para> </para>
</listitem> </listitem>
......
...@@ -970,7 +970,7 @@ CREATE MATERIALIZED VIEW sales_summary AS ...@@ -970,7 +970,7 @@ CREATE MATERIALIZED VIEW sales_summary AS
invoice_date, invoice_date,
sum(invoice_amt)::numeric(13,2) as sales_amt sum(invoice_amt)::numeric(13,2) as sales_amt
FROM invoice FROM invoice
WHERE invoice_date < CURRENT_DATE WHERE invoice_date &lt; CURRENT_DATE
GROUP BY GROUP BY
seller_no, seller_no,
invoice_date invoice_date
...@@ -1058,7 +1058,7 @@ SELECT count(*) FROM words WHERE word = 'caterpiler'; ...@@ -1058,7 +1058,7 @@ SELECT count(*) FROM words WHERE word = 'caterpiler';
have wanted. Again using <literal>file_fdw</literal>: have wanted. Again using <literal>file_fdw</literal>:
<programlisting> <programlisting>
SELECT word FROM words ORDER BY word <-> 'caterpiler' LIMIT 10; SELECT word FROM words ORDER BY word &lt;-&gt; 'caterpiler' LIMIT 10;
word word
--------------- ---------------
......
...@@ -1725,7 +1725,7 @@ SELECT percentile_cont(0.5) WITHIN GROUP (ORDER BY income) FROM households; ...@@ -1725,7 +1725,7 @@ SELECT percentile_cont(0.5) WITHIN GROUP (ORDER BY income) FROM households;
<programlisting> <programlisting>
SELECT SELECT
count(*) AS unfiltered, count(*) AS unfiltered,
count(*) FILTER (WHERE i < 5) AS filtered count(*) FILTER (WHERE i &lt; 5) AS filtered
FROM generate_series(1,10) AS s(i); FROM generate_series(1,10) AS s(i);
unfiltered | filtered unfiltered | filtered
------------+---------- ------------+----------
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment