1
1
<!--
2
- $Header: /cvsroot/pgsql/doc/src/sgml/syntax.sgml,v 1.38 2001/01/26 22:04:22 petere Exp $
2
+ $Header: /cvsroot/pgsql/doc/src/sgml/syntax.sgml,v 1.39 2001/02/10 07:08:44 tgl Exp $
3
3
-->
4
4
5
5
<chapter id="sql-syntax">
@@ -49,7 +49,7 @@ INSERT INTO MY_TABLE VALUES (3, 'hi there');
49
49
</programlisting>
50
50
This is a sequence of three commands, one per line (although this
51
51
is not required; more than one command can be on a line, and
52
- commands can be usefully split across lines).
52
+ commands can usefully be split across lines).
53
53
</para>
54
54
</informalexample>
55
55
@@ -115,7 +115,7 @@ UPDATE MY_TABLE SET A = 5;
115
115
<programlisting>
116
116
uPDaTE my_TabLE SeT a = 5;
117
117
</programlisting>
118
- A good convention to adopt is perhaps to write key words in upper
118
+ A convention often used is to write key words in upper
119
119
case and names in lower case, e.g.,
120
120
<programlisting>
121
121
UPDATE my_table SET a = 5;
@@ -131,10 +131,10 @@ UPDATE my_table SET a = 5;
131
131
identifier is always an identifier, never a key word. So
132
132
<literal>"select"</literal> could be used to refer to a column or
133
133
table named <quote>select</quote>, whereas an unquoted
134
- <literal>select</literal> would be taken as part of a command and
134
+ <literal>select</literal> would be taken as a key word and
135
135
would therefore provoke a parse error when used where a table or
136
136
column name is expected. The example can be written with quoted
137
- identifiers like so :
137
+ identifiers like this :
138
138
<programlisting>
139
139
UPDATE "my_table" SET "a" = 5;
140
140
</programlisting>
@@ -157,11 +157,13 @@ UPDATE "my_table" SET "a" = 5;
157
157
each other.
158
158
<footnote>
159
159
<para>
160
- This is incompatible with SQL, where unquoted names are folded to
161
- upper case. Thus, <literal>foo</literal> is equivalent to
162
- <literal>"FOO"</literal>. If you want to write portable
163
- applications you are advised to always quote a particular name or
164
- never quote it.
160
+ <productname>Postgres</productname>' folding of unquoted names to lower
161
+ case is incompatible with the SQL standard, which says that unquoted
162
+ names should be folded to upper case. Thus, <literal>foo</literal>
163
+ should be equivalent to <literal>"FOO"</literal> not
164
+ <literal>"foo"</literal> according to the standard. If you want to
165
+ write portable applications you are advised to always quote a particular
166
+ name or never quote it.
165
167
</para>
166
168
</footnote>
167
169
</para>
@@ -241,7 +243,7 @@ SELECT 'foo' 'bar';
241
243
opening quote (no intervening whitespace), e.g.,
242
244
<literal>B'1001'</literal>. The only characters allowed within
243
245
bit string constants are <literal>0</literal> and
244
- <literal>1</literal>. Bit strings constants can be continued
246
+ <literal>1</literal>. Bit string constants can be continued
245
247
across lines in the same way as regular string constants.
246
248
</para>
247
249
</sect3>
@@ -271,7 +273,7 @@ SELECT 'foo' 'bar';
271
273
</synopsis>
272
274
where <replaceable>digits</replaceable> is one or more decimal
273
275
digits. At least one digit must be before or after the decimal
274
- point and after the <literal>e</literal> if you use that option.
276
+ point, and after the <literal>e</literal> if you use that option.
275
277
Thus, a floating point constant is distinguished from an integer
276
278
constant by the presence of either the decimal point or the
277
279
exponent clause (or both). There must not be a space or other
@@ -486,8 +488,8 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
486
488
<listitem>
487
489
<para>
488
490
The semicolon (<literal>;</literal>) terminates an SQL command.
489
- It cannot appear anywhere within a command, except when quoted
490
- as a string constant or identifier.
491
+ It cannot appear anywhere within a command, except within a
492
+ string constant or quoted identifier.
491
493
</para>
492
494
</listitem>
493
495
@@ -648,7 +650,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
648
650
<para>
649
651
For further information on the system attributes consult
650
652
<xref linkend="STON87a" endterm="STON87a">.
651
- Transaction and command identifiers are 32 bit quantities.
653
+ Transaction and command identifiers are 32- bit quantities.
652
654
</para>
653
655
654
656
</sect1>
@@ -658,7 +660,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
658
660
<title>Value Expressions</title>
659
661
660
662
<para>
661
- Value expressions are used in a variety of syntactic contexts, such
663
+ Value expressions are used in a variety of contexts, such
662
664
as in the target list of the <command>SELECT</command> command, as
663
665
new column values in <command>INSERT</command> or
664
666
<command>UPDATE</command>, or in search conditions in a number of
@@ -692,13 +694,13 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
692
694
An operator invocation:
693
695
<simplelist>
694
696
<member><replaceable>expression</replaceable> <replaceable>operator</replaceable> <replaceable>expression</replaceable> (binary infix operator)</member>
695
- <member><replaceable>expression</replaceable> <replaceable>operator</replaceable> (unary postfix operator)</member>
696
697
<member><replaceable>operator</replaceable> <replaceable>expression</replaceable> (unary prefix operator)</member>
698
+ <member><replaceable>expression</replaceable> <replaceable>operator</replaceable> (unary postfix operator)</member>
697
699
</simplelist>
698
700
where <replaceable>operator</replaceable> follows the syntax
699
701
rules of <xref linkend="sql-syntax-operators"> or is one of the
700
702
tokens <token>AND</token>, <token>OR</token>, and
701
- <token>NOT</token>. What particular operators exist and whether
703
+ <token>NOT</token>. Which particular operators exist and whether
702
704
they are unary or binary depends on what operators have been
703
705
defined by the system or the user. <xref linkend="functions">
704
706
describes the built-in operators.
@@ -733,7 +735,7 @@ CAST ( '<replaceable>string</replaceable>' AS <replaceable>type</replaceable> )
733
735
<listitem>
734
736
<para>
735
737
A scalar subquery. This is an ordinary
736
- <command>SELECT</command> in parenthesis that returns exactly one
738
+ <command>SELECT</command> in parentheses that returns exactly one
737
739
row with one column. It is an error to use a subquery that
738
740
returns more than one row or more than one column in the context
739
741
of a value expression.
@@ -813,9 +815,9 @@ CREATE FUNCTION dept (text) RETURNS dept
813
815
<title>Function Calls</title>
814
816
815
817
<para>
816
- The syntax for a function call is the name of a legal function
817
- (subject to the syntax rules for identifiers of <xref
818
- linkend="sql-syntax-identifiers"> , followed by its argument list
818
+ The syntax for a function call is the name of a function
819
+ (which is subject to the syntax rules for identifiers of <xref
820
+ linkend="sql-syntax-identifiers">) , followed by its argument list
819
821
enclosed in parentheses:
820
822
821
823
<synopsis>
@@ -862,7 +864,9 @@ sqrt(2)
862
864
<para>
863
865
The first form of aggregate expression invokes the aggregate
864
866
across all input rows for which the given expression yields a
865
- non-NULL value. The second form is the same as the first, since
867
+ non-NULL value. (Actually, it is up to the aggregate function
868
+ whether to ignore NULLs or not --- but all the standard ones do.)
869
+ The second form is the same as the first, since
866
870
<literal>ALL</literal> is the default. The third form invokes the
867
871
aggregate for all distinct non-NULL values of the expression found
868
872
in the input rows. The last form invokes the aggregate once for
@@ -881,7 +885,8 @@ sqrt(2)
881
885
882
886
<para>
883
887
The predefined aggregate functions are described in <xref
884
- linkend="functions-aggregate">.
888
+ linkend="functions-aggregate">. Other aggregate functions may be added
889
+ by the user.
885
890
</para>
886
891
</sect2>
887
892
@@ -900,15 +905,19 @@ sqrt(2)
900
905
you will sometimes need to add parentheses when using combinations
901
906
of binary and unary operators. For instance
902
907
<programlisting>
903
- SELECT 5 & ~ 6;
908
+ SELECT 5 ! ~ 6;
904
909
</programlisting>
905
910
will be parsed as
906
911
<programlisting>
907
- SELECT (5 &) ~ 6;
912
+ SELECT 5 ! (~ 6);
913
+ </programlisting>
914
+ because the parser has no idea --- until it's too late --- that
915
+ <token>!</token> is defined as a postfix operator not an infix one.
916
+ To get the desired behavior in this case, you must write
917
+ <programlisting>
918
+ SELECT (5 !) ~ 6;
908
919
</programlisting>
909
- because the parser has no idea that <token>&</token> is
910
- defined as a binary operator. This is the price one pays for
911
- extensibility.
920
+ This is the price one pays for extensibility.
912
921
</para>
913
922
914
923
<table tocentry="1">
0 commit comments