Uppercase keywords where appropriate.

doc/src/sgml/gist.sgml

@@ -51,8 +51,8 @@ to check that. Other examples also worked, except polygons: I got an
 error doing
 
 <ProgramListing>
-test=> create index pix on polytmp
-test-> using gist (p:box gist_poly_ops) with (islossy);
+test=> CREATE INDEX pix ON polytmp
+test-> USING GIST (p:box gist_poly_ops) WITH (ISLOSSY);
 ERROR:  cannot open pix
 
 (PostgreSQL 6.3               Sun Feb  1 14:57:30 EST 1998)
@@ -92,7 +92,7 @@ A few notes on the sources:
 
 <ProgramListing>
 -- -- there's a memory leak in rtree poly_ops!!
--- -- create index pix2 on polytmp using rtree (p poly_ops);
+-- -- CREATE INDEX pix2 ON polytmp USING RTREE (p poly_ops);
 </ProgramListing>
 
    Roger that!! I thought it could be related to a number of

doc/src/sgml/jdbc.sgml

 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/Attic/jdbc.sgml,v 1.25 2001/09/13 15:55:22 petere Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/Attic/jdbc.sgml,v 1.26 2001/10/12 23:32:33 momjian Exp $
 -->
 
  <chapter id="jdbc">
@@ -2311,21 +2311,21 @@ public void unlink(int oid) throws SQLException
     One of the consequences of this, is that you can have one table
     refer to a row in another table.  For example:
 <screen>
-test=> create table users (username name,fullname text);
+test=> CREATE TABLE users (username NAME,fullname TEXT);
 CREATE
-test=> create table server (servername name,adminuser users);
+test=> CREATE TABLE server (servername NAME,adminuser users);
 CREATE
-test=> insert into users values ('peter','Peter Mount');
+test=> INSERT INTO users VALUES ('peter','Peter Mount');
 INSERT 2610132 1
-test=> insert into server values ('maidast',2610132::users);
+test=> INSERT INTO server VALUES ('maidast',2610132::users);
 INSERT 2610133 1
-test=> select * from users;
+test=> SELECT * FROM users;
 username|fullname      
 --------+--------------
 peter   |Peter Mount   
 (1 row)
 
-test=> select * from server;
+test=> SELECT * FROM server;
 servername|adminuser
 ----------+---------
 maidast   |  2610132

doc/src/sgml/libpgtcl.sgml

@@ -917,7 +917,7 @@ given chunk of code for each tuple in the result.
 This would work if table <classname>table</> has fields <structfield>control</> and <structfield>name</>
 (and, perhaps, other fields):
 <ProgramListing>
-	pg_select $pgconn "SELECT * from table" array {
+	pg_select $pgconn "SELECT * FROM table" array {
 		puts [format "%5d %s" array(control) array(name)]
 	}
 </ProgramListing>

doc/src/sgml/libpq++.sgml

 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/Attic/libpq++.sgml,v 1.32 2001/09/13 15:55:23 petere Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/Attic/libpq++.sgml,v 1.33 2001/10/12 23:32:34 momjian Exp $
 -->
 
  <chapter id="libpqplusplus">
@@ -794,8 +794,8 @@ $Header: /cvsroot/pgsql/doc/src/sgml/Attic/libpq++.sgml,v 1.32 2001/09/13 15:55:
     
     <programlisting>
 PgDatabase data;
-data.Exec("create table foo (a int4, b char(16), d double precision)");
-data.Exec("copy foo from stdin");
+data.Exec("CREATE TABLE foo (a int4, b char(16), d double precision)");
+data.Exec("COPY foo FROM STDIN");
 data.PutLine("3\tHello World\t4.5\n");
 data.PutLine("4\tGoodbye World\t7.11\n");
 &amp;...

doc/src/sgml/libpq.sgml

 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/libpq.sgml,v 1.72 2001/09/13 15:55:23 petere Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/libpq.sgml,v 1.73 2001/10/12 23:32:34 momjian Exp $
 -->
 
  <chapter id="libpq">
@@ -302,11 +302,11 @@ PostgresPollingStatusType PQconnectPoll(PGconn *conn)
    proceed with the connection sequence.  Loop thus: Consider a connection
    <quote>inactive</quote> by default. If <function>PQconnectPoll</function> last returned <symbol>PGRES_POLLING_ACTIVE</>,
    consider it <quote>active</quote> instead. If <function>PQconnectPoll(conn)</function> last returned
-   <symbol>PGRES_POLLING_READING</symbol>, perform a select for reading on <function>PQsocket(conn)</function>. If
-   it last returned <symbol>PGRES_POLLING_WRITING</symbol>, perform a select for writing on
+   <symbol>PGRES_POLLING_READING</symbol>, perform a SELECT for reading on <function>PQsocket(conn)</function>. If
+   it last returned <symbol>PGRES_POLLING_WRITING</symbol>, perform a SELECT for writing on
    <function>PQsocket(conn)</function>. If you have yet to call <function>PQconnectPoll</function>, i.e. after the call
    to <function>PQconnectStart</function>, behave as if it last returned <symbol>PGRES_POLLING_WRITING</symbol>.  If
-   the select shows that the socket is ready, consider it <quote>active</quote>. If it has
+   the SELECT shows that the socket is ready, consider it <quote>active</quote>. If it has
    been decided that this connection is <quote>active</quote>, call <function>PQconnectPoll(conn)</function>
    again. If this call returns <symbol>PGRES_POLLING_FAILED</symbol>, the connection procedure
    has failed.  If this call returns <symbol>PGRES_POLLING_OK</symbol>, the connection has been
@@ -1763,8 +1763,8 @@ int PQendcopy(PGconn *conn);
 As an example:
 
 <programlisting>
-PQexec(conn, "create table foo (a int4, b char(16), d double precision)");
-PQexec(conn, "copy foo from stdin");
+PQexec(conn, "CREATE TABLE foo (a int4, b char(16), d double precision)");
+PQexec(conn, "COPY foo FROM STDIN");
 PQputline(conn, "3\thello world\t4.5\n");
 PQputline(conn,"4\tgoodbye world\t7.11\n");
 ...
@@ -2270,7 +2270,7 @@ main()
      * fetch rows from the pg_database, the system catalog of
      * databases
      */
-    res = PQexec(conn, "DECLARE mycursor CURSOR FOR select * from pg_database");
+    res = PQexec(conn, "DECLARE mycursor CURSOR FOR SELECT * FROM pg_database");
     if (!res || PQresultStatus(res) != PGRES_COMMAND_OK)
     {
         fprintf(stderr, "DECLARE CURSOR command failed\n");
@@ -2541,7 +2541,7 @@ main()
      * fetch rows from the pg_database, the system catalog of
      * databases
      */
-    res = PQexec(conn, "DECLARE mycursor BINARY CURSOR FOR select * from test1");
+    res = PQexec(conn, "DECLARE mycursor BINARY CURSOR FOR SELECT * FROM test1");
     if (!res || PQresultStatus(res) != PGRES_COMMAND_OK)
     {
         fprintf(stderr, "DECLARE CURSOR command failed\n");

doc/src/sgml/maintenance.sgml

 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v 1.4 2001/09/23 04:06:24 momjian Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v 1.5 2001/10/12 23:32:34 momjian Exp $
 -->
 
 <chapter id="maintenance">
@@ -304,7 +304,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v 1.4 2001/09/23 04:06:24
     examine this information is to execute the query
     <informalexample>
 <programlisting>
-select datname, age(datfrozenxid) from pg_database;
+SELECT datname, age(datfrozenxid) FROM pg_database;
 </programlisting>
     </informalexample>
     The <literal>age</> column measures the number of transactions from the

doc/src/sgml/perform.sgml

 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/perform.sgml,v 1.11 2001/10/09 18:46:00 petere Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/perform.sgml,v 1.12 2001/10/12 23:32:34 momjian Exp $
 -->
 
  <chapter id="performance-tips">
@@ -95,7 +95,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/perform.sgml,v 1.11 2001/10/09 18:46:00 pet
     vacuum analyze, and 7.2 development sources):
 
     <programlisting>
-regression=# explain select * from tenk1;
+regression=# EXPLAIN SELECT * FROM tenk1;
 NOTICE:  QUERY PLAN:
 
 Seq Scan on tenk1  (cost=0.00..333.00 rows=10000 width=148)
@@ -106,7 +106,7 @@ Seq Scan on tenk1  (cost=0.00..333.00 rows=10000 width=148)
     This is about as straightforward as it gets.  If you do
 
     <programlisting>
-select * from pg_class where relname = 'tenk1';
+SELECT * FROM pg_class WHERE relname = 'tenk1';
     </programlisting>
 
     you will find out that <classname>tenk1</classname> has 233 disk
@@ -119,7 +119,7 @@ select * from pg_class where relname = 'tenk1';
     Now let's modify the query to add a qualification clause:
 
     <programlisting>
-regression=# explain select * from tenk1 where unique1 &lt; 1000;
+regression=# EXPLAIN SELECT * FROM tenk1 WHERE unique1 &lt; 1000;
 NOTICE:  QUERY PLAN:
 
 Seq Scan on tenk1  (cost=0.00..358.00 rows=1007 width=148)
@@ -144,7 +144,7 @@ Seq Scan on tenk1  (cost=0.00..358.00 rows=1007 width=148)
     Modify the query to restrict the qualification even more:
 
     <programlisting>
-regression=# explain select * from tenk1 where unique1 &lt; 50;
+regression=# EXPLAIN SELECT * FROM tenk1 WHERE unique1 &lt; 50;
 NOTICE:  QUERY PLAN:
 
 Index Scan using tenk1_unique1 on tenk1  (cost=0.00..181.09 rows=49 width=148)
@@ -162,7 +162,7 @@ Index Scan using tenk1_unique1 on tenk1  (cost=0.00..181.09 rows=49 width=148)
     Add another condition to the qualification:
 
     <programlisting>
-regression=# explain select * from tenk1 where unique1 &lt; 50 and
+regression=# EXPLAIN SELECT * FROM tenk1 WHERE unique1 &lt; 50 AND
 regression-# stringu1 = 'xxx';
 NOTICE:  QUERY PLAN:
 
@@ -177,8 +177,8 @@ Index Scan using tenk1_unique1 on tenk1  (cost=0.00..181.22 rows=1 width=148)
     Let's try joining two tables, using the fields we have been discussing:
 
     <programlisting>
-regression=# explain select * from tenk1 t1, tenk2 t2 where t1.unique1 &lt; 50
-regression-# and t1.unique2 = t2.unique2;
+regression=# EXPLAIN SELECT * FROM tenk1 t1, tenk2 t2 WHERE t1.unique1 &lt; 50
+regression-# AND t1.unique2 = t2.unique2;
 NOTICE:  QUERY PLAN:
 
 Nested Loop  (cost=0.00..330.41 rows=49 width=296)
@@ -225,8 +225,8 @@ Nested Loop  (cost=0.00..330.41 rows=49 width=296)
     <programlisting>
 regression=# set enable_nestloop = off;
 SET VARIABLE
-regression=# explain select * from tenk1 t1, tenk2 t2 where t1.unique1 &lt; 50
-regression-# and t1.unique2 = t2.unique2;
+regression=# EXPLAIN SELECT * FROM tenk1 t1, tenk2 t2 WHERE t1.unique1 &lt; 50
+regression-# AND t1.unique2 = t2.unique2;
 NOTICE:  QUERY PLAN:
 
 Hash Join  (cost=181.22..564.83 rows=49 width=296)
@@ -257,9 +257,9 @@ Hash Join  (cost=181.22..564.83 rows=49 width=296)
     For example, we might get a result like this:
 
 <screen>
-regression=# explain analyze
-regression-# select * from tenk1 t1, tenk2 t2
-regression-#          where t1.unique1 &lt; 50 and t1.unique2 = t2.unique2;
+regression=# EXPLAIN ANALYZE
+regression-# SELECT * FROM tenk1 t1, tenk2 t2
+regression-# WHERE t1.unique1 &lt; 50 AND t1.unique2 = t2.unique2;
 NOTICE:  QUERY PLAN:
 
 Nested Loop  (cost=0.00..330.41 rows=49 width=296) (actual time=1.31..28.90 rows=50 loops=1)

doc/src/sgml/spi.sgml

@@ -447,7 +447,7 @@ Maximum number of tuples to return
    which the query will be executed. For example,
 
 <ProgramListing>
-SPI_exec ("insert into table select * from table", 5);
+SPI_exec ("INSERT INTO tab SELECT * FROM tab", 5);
 </ProgramListing>
 
 will allow at most 5 tuples to be inserted into table.
@@ -2821,19 +2821,19 @@ execq(text *sql, int cnt)
    Now, compile and create the function:
 
 <ProgramListing>
-create function execq (text, int4) returns int4 as '...path_to_so' language 'c';
+CREATE FUNCTION execq (TEXT, INT4) RETURNS INT4 AS '...path_to_so' LANGUAGE 'c';
 </ProgramListing>
 
 <ProgramListing>
-vac=> select execq('create table a (x int4)', 0);
+vac=> SELECT execq('CREATE TABLE a (x INT4)', 0);
 execq
 -----
     0
 (1 row)
 
-vac=> insert into a values (execq('insert into a values (0)',0));
+vac=> INSERT INTO a VALUES (execq('INSERT INTO a VALUES (0)',0));
 INSERT 167631 1
-vac=> select execq('select * from a',0);
+vac=> select execq('SELECT * FROM a',0);
 NOTICE:EXECQ:  0 <<< inserted by execq
 
 NOTICE:EXECQ:  1 <<< value returned by execq and inserted by upper INSERT
@@ -2843,13 +2843,13 @@ execq
     2
 (1 row)
 
-vac=> select execq('insert into a select x + 2 from a',1);
+vac=> SELECT execq('INSERT INTO a SELECT x + 2 FROM a',1);
 execq
 -----
     1
 (1 row)
 
-vac=> select execq('select * from a', 10);
+vac=> SELECT execq('SELECT * FROM a', 10);
 NOTICE:EXECQ:  0 
 
 NOTICE:EXECQ:  1 
@@ -2861,20 +2861,20 @@ execq
     3            <<< 10 is max value only, 3 is real # of tuples
 (1 row)
 
-vac=> delete from a;
+vac=> DELETE FROM a;
 DELETE 3
-vac=> insert into a values (execq('select * from a', 0) + 1);
+vac=> INSERT INTO a VALUES (execq('SELECT * FROM a', 0) + 1);
 INSERT 167712 1
-vac=> select * from a;
+vac=> SELECT * FROM a;
 x
 -
 1                <<< no tuples in a (0) + 1
 (1 row)
 
-vac=> insert into a values (execq('select * from a', 0) + 1);
+vac=> INSERT INTO a VALUES (execq('SELECT * FROM a', 0) + 1);
 NOTICE:EXECQ:  0 
 INSERT 167713 1
-vac=> select * from a;
+vac=> SELECT * FROM a;
 x
 -
 1
@@ -2883,14 +2883,14 @@ x
 
 --   This demonstrates data changes visibility rule:
 
-vac=> insert into a select execq('select * from a', 0) * x from a;
+vac=> INSERT INTO a SELECT execq('SELECT * FROM a', 0) * x FROM a;
 NOTICE:EXECQ:  1 
 NOTICE:EXECQ:  2 
 NOTICE:EXECQ:  1 
 NOTICE:EXECQ:  2 
 NOTICE:EXECQ:  2 
 INSERT 0 2
-vac=> select * from a;
+vac=> SELECT * FROM a;
 x
 -
 1

doc/src/sgml/syntax.sgml

 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/syntax.sgml,v 1.48 2001/10/09 18:46:00 petere Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/syntax.sgml,v 1.49 2001/10/12 23:32:34 momjian Exp $
 -->
 
 <chapter id="sql-syntax">
@@ -909,7 +909,7 @@ $<replaceable>number</replaceable>
 
 <programlisting>
 CREATE FUNCTION dept (text) RETURNS dept
-  AS 'select * from dept where name = $1'
+  AS 'SELECT * FROM dept WHERE name = $1'
   LANGUAGE 'sql';
 </programlisting>
 

doc/src/sgml/trigger.sgml

@@ -486,7 +486,7 @@ trigf(PG_FUNCTION_ARGS)
 		elog(NOTICE, "trigf (fired %s): SPI_connect returned %d", when, ret);
 	
 	/* Get number of tuples in relation */
-	ret = SPI_exec("select count(*) from ttest", 0);
+	ret = SPI_exec("SELECT count(*) FROM ttest", 0);
 	
 	if (ret < 0)
 		elog(NOTICE, "trigf (fired %s): SPI_exec returned %d", when, ret);
@@ -513,70 +513,70 @@ trigf(PG_FUNCTION_ARGS)
     Now, compile and create the trigger function:
 
     <programlisting>
-create function trigf () returns opaque as 
-'...path_to_so' language 'C';
+CREATE FUNCTION trigf () RETURNS OPAQUE AS 
+'...path_to_so' LANGUAGE 'C';
 
-create table ttest (x int4);
+CREATE TABLE ttest (x int4);
     </programlisting>
 
     <programlisting>
-vac=> create trigger tbefore before insert or update or delete on ttest 
-for each row execute procedure trigf();
+vac=> CREATE TRIGGER tbefore BEFORE INSERT OR UPDATE OR DELETE ON ttest 
+FOR EACH ROW EXECUTE PROCEDURE trigf();
 CREATE
-vac=> create trigger tafter after insert or update or delete on ttest 
-for each row execute procedure trigf();
+vac=> CREATE TRIGGER tafter AFTER INSERT OR UPDATE OR DELETE ON ttest 
+FOR EACH ROW EXECUTE PROCEDURE trigf();
 CREATE
-vac=> insert into ttest values (null);
+vac=> INSERT INTO ttest VALUES (NULL);
 NOTICE:trigf (fired before): there are 0 tuples in ttest
 INSERT 0 0
 
 -- Insertion skipped and AFTER trigger is not fired
 
-vac=> select * from ttest;
+vac=> SELECT * FROM ttest;
 x
 -
 (0 rows)
 
-vac=> insert into ttest values (1);
+vac=> INSERT INTO ttest VALUES (1);
 NOTICE:trigf (fired before): there are 0 tuples in ttest
 NOTICE:trigf (fired after ): there are 1 tuples in ttest
                                        ^^^^^^^^
                              remember what we said about visibility.
 INSERT 167793 1
-vac=> select * from ttest;
+vac=> SELECT * FROM ttest;
 x
 -
 1
 (1 row)
 
-vac=> insert into ttest select x * 2 from ttest;
+vac=> INSERT INTO ttest SELECT x * 2 FROM ttest;
 NOTICE:trigf (fired before): there are 1 tuples in ttest
 NOTICE:trigf (fired after ): there are 2 tuples in ttest
                                        ^^^^^^^^
                              remember what we said about visibility.
 INSERT 167794 1
-vac=> select * from ttest;
+vac=> SELECT * FROM ttest;
 x
 -
 1
 2
 (2 rows)
 
-vac=> update ttest set x = null where x = 2;
+vac=> UPDATE ttest SET x = null WHERE x = 2;
 NOTICE:trigf (fired before): there are 2 tuples in ttest
 UPDATE 0
-vac=> update ttest set x = 4 where x = 2;
+vac=> UPDATE ttest SET x = 4 WHERE x = 2;
 NOTICE:trigf (fired before): there are 2 tuples in ttest
 NOTICE:trigf (fired after ): there are 2 tuples in ttest
 UPDATE 1
-vac=> select * from ttest;
+vac=> SELECT * FROM ttest;
 x
 -
 1
 4
 (2 rows)
 
-vac=> delete from ttest;
+vac=> DELETE FROM ttest;
 NOTICE:trigf (fired before): there are 2 tuples in ttest
 NOTICE:trigf (fired after ): there are 1 tuples in ttest
 NOTICE:trigf (fired before): there are 1 tuples in ttest
@@ -584,7 +584,7 @@ NOTICE:trigf (fired after ): there are 0 tuples in ttest
                                        ^^^^^^^^
                              remember what we said about visibility.
 DELETE 2
-vac=> select * from ttest;
+vac=> SELECT * FROM ttest;
 x
 -
 (0 rows)

doc/src/sgml/typeconv.sgml

@@ -281,19 +281,18 @@ If only one candidate remains, use it; else continue to the next step.
 </step>
 <step performance="required">
 <para>
-If any input arguments are <quote>unknown</quote>, check the type categories accepted
-at those argument positions by the remaining candidates.  At each position,
-select "string"
-category if any candidate accepts that category (this bias towards string
-is appropriate since an unknown-type literal does look like a string).
-Otherwise, if all the remaining candidates accept the same type category,
-select that category; otherwise fail because
-the correct choice cannot be deduced without more clues.  Also note whether
-any of the candidates accept a preferred data type within the selected category.
-Now discard operator candidates that do not accept the selected type category;
-furthermore, if any candidate accepts a preferred type at a given argument
-position, discard candidates that accept non-preferred types for that
-argument.
+If any input arguments are <quote>unknown</quote>, check the type
+categories accepted at those argument positions by the remaining
+candidates.  At each position, try the "string" category if any
+candidate accepts that category (this bias towards string is appropriate
+since an unknown-type literal does look like a string). Otherwise, if
+all the remaining candidates accept the same type category, select that
+category; otherwise fail because the correct choice cannot be deduced
+without more clues.  Also note whether any of the candidates accept a
+preferred data type within the selected category. Now discard operator
+candidates that do not accept the selected type category; furthermore,
+if any candidate accepts a preferred type at a given argument position,
+discard candidates that accept non-preferred types for that argument.
 </para>
 </step>
 <step performance="required">
@@ -319,7 +318,7 @@ operator defined in the catalog, and it takes arguments of type
 The scanner assigns an initial type of <type>integer</type> to both arguments
 of this query expression:
 <screen>
-tgl=> select 2 ^ 3 AS "Exp";
+tgl=> SELECT 2 ^ 3 AS "Exp";
  Exp
 -----
    8
@@ -330,7 +329,7 @@ So the parser does a type conversion on both operands and the query
 is equivalent to
 
 <screen>
-tgl=> select CAST(2 AS double precision) ^ CAST(3 AS double precision) AS "Exp";
+tgl=> SELECT CAST(2 AS double precision) ^ CAST(3 AS double precision) AS "Exp";
  Exp
 -----
    8
@@ -340,7 +339,7 @@ tgl=> select CAST(2 AS double precision) ^ CAST(3 AS double precision) AS "Exp";
 or
 
 <screen>
-tgl=> select 2.0 ^ 3.0 AS "Exp";
+tgl=> SELECT 2.0 ^ 3.0 AS "Exp";
  Exp
 -----
    8
@@ -417,7 +416,7 @@ will try to convert that argument to an integer for evaluation of the
 factorial.
 
 <screen>
-tgl=> select (4.3 !);
+tgl=> SELECT (4.3 !);
  ?column?
 ----------
        24
@@ -508,8 +507,7 @@ If only one candidate remains, use it; else continue to the next step.
 <para>
 If any input arguments are <type>unknown</type>, check the type categories accepted
 at those argument positions by the remaining candidates.  At each position,
-select <type>string</type>
-category if any candidate accepts that category (this bias towards string
+try the <type>string</type> category if any candidate accepts that category (this bias towards string
 is appropriate since an unknown-type literal does look like a string).
 Otherwise, if all the remaining candidates accept the same type category,
 select that category; otherwise fail because
@@ -543,7 +541,7 @@ So the following query automatically converts the <type>int2</type> argument
 to <type>int4</type>:
 
 <screen>
-tgl=> select int4fac(int2 '4');
+tgl=> SELECT int4fac(int2 '4');
  int4fac
 ---------
       24
@@ -552,7 +550,7 @@ tgl=> select int4fac(int2 '4');
 
 and is actually transformed by the parser to
 <screen>
-tgl=> select int4fac(int4(int2 '4'));
+tgl=> SELECT int4fac(int4(int2 '4'));
  int4fac
 ---------
       24
@@ -573,7 +571,7 @@ only one takes two arguments, of types <type>text</type> and <type>int4</type>.
 If called with a string constant of unspecified type, the type is matched up
 directly with the only candidate function type:
 <screen>
-tgl=> select substr('1234', 3);
+tgl=> SELECT substr('1234', 3);
  substr
 --------
      34
@@ -585,7 +583,7 @@ tgl=> select substr('1234', 3);
 If the string is declared to be of type <type>varchar</type>, as might be the case
 if it comes from a table, then the parser will try to coerce it to become <type>text</type>:
 <screen>
-tgl=> select substr(varchar '1234', 3);
+tgl=> SELECT substr(varchar '1234', 3);
  substr
 --------
      34
@@ -593,7 +591,7 @@ tgl=> select substr(varchar '1234', 3);
 </screen>
 which is transformed by the parser to become
 <screen>
-tgl=> select substr(text(varchar '1234'), 3);
+tgl=> SELECT substr(text(varchar '1234'), 3);
  substr
 --------
      34
@@ -615,7 +613,7 @@ explicit type conversion call is really inserted in this case.
 And, if the function is called with an <type>int4</type>, the parser will
 try to convert that to <type>text</type>:
 <screen>
-tgl=> select substr(1234, 3);
+tgl=> SELECT substr(1234, 3);
  substr
 --------
      34
@@ -623,7 +621,7 @@ tgl=> select substr(1234, 3);
 </screen>
 actually executes as
 <screen>
-tgl=> select substr(text(1234), 3);
+tgl=> SELECT substr(text(1234), 3);
  substr
 --------
      34