whitespace.
-
For example, the following is (syntactically) valid SQL input:
is not required; more than one command can be on a line, and
commands can usefully be split across lines).
-
The SQL syntax is not very consistent regarding what tokens
characters embedded in the constant.
-
- These are some examples of valid floating-point constants:
-
+ These are some examples of valid floating-point constants:
+
3.5
4.
.001
5e2
1.925e-3
-
-
-
+
+
Floating-point constants are of type DOUBLE
by using
SQL string notation or
PostgreSQL type notation:
REAL '1.23' -- string style
'1.23'::REAL -- PostgreSQL (historical) style
-
+
analysis and is effectively replaced by whitespace.
+
+
+
Lexical Precedence
+
+
+ precedence
+
+
+ The precedence and associativity of the operators is hard-wired
+ into the parser. Most operators have the same precedence and are
+ left-associative. This may lead to non-intuitive behavior; for
+ example the Boolean operators < and > have a different
+ precedence than the Boolean operators <= and >=. Also,
+ you will sometimes need to add parentheses when using combinations
+ of binary and unary operators. For instance
+SELECT 5 ! - 6;
+
+ will be parsed as
+SELECT 5 ! (- 6);
+
+ because the parser has no idea -- until it is too late -- that
+ ! is defined as a postfix operator, not an infix one.
+ To get the desired behavior in this case, you must write
+SELECT (5 !) - 6;
+
+ This is the price one pays for extensibility.
+
+
+
Operator Precedence (decreasing)
+
+
+
+ |
+ Operator/Element
+ Associativity
+ Description
+
+
+
+
+ |
+ .
+ left
+ table/column name separator
+
+
+ |
+ ::
+ left
+
PostgreSQL-style typecast+
+
+ |
+ [ ]
+ left
+ array element selection
+
+
+ |
+ -
+ right
+ unary minus
+
+
+ |
+ ^
+ left
+ exponentiation
+
+
+ |
+ * / %
+ left
+ multiplication, division, modulo
+
+
+ |
+ + -
+ left
+ addition, subtraction
+
+
+ |
+ IS
+
+ test for TRUE, FALSE, UNKNOWN, NULL
+
+
+ |
+ ISNULL
+
+ test for NULL
+
+
+ |
+ NOTNULL
+
+ test for NOT NULL
+
+
+ |
+ (any other)
+ left
+ all other native and user-defined operators
+
+
+ |
+ IN
+
+ set membership
+
+
+ |
+ BETWEEN
+
+ containment
+
+
+ |
+ OVERLAPS
+
+ time interval overlap
+
+
+ |
+ LIKE ILIKE
+
+ string pattern matching
+
+
+ |
+ < >
+
+ less than, greater than
+
+
+ |
+ =
+ right
+ equality, assignment
+
+
+ |
+ NOT
+ right
+ logical negation
+
+
+ |
+ AND
+ left
+ logical conjunction
+
+
+ |
+ OR
+ left
+ logical disjunction
+
+
+
+
+
+ Note that the operator precedence rules also apply to user-defined
+ operators that have the same names as the built-in operators
+ mentioned above. For example, if you define a
+ +
operator for some custom data type it will have
+ the same precedence as the built-in +
operator, no
+ matter what yours does.
+
+
need to write a qualified operator name in an expression, there is a
special provision: you must write
- OPERATOR(schema.operator)
+OPERATOR(schema.operator)
This is needed to avoid syntactic ambiguity. An example is
- SELECT 3 OPERATOR(pg_catalog.+) 4;
+SELECT 3 OPERATOR(pg_catalog.+) 4;
In practice one usually relies on the search path for operators,
so as not to have to write anything so ugly as that.
-
-
-
-
-
Lexical Precedence
+
+
Expression Evaluation
-
- precedence
-
+ The order of evaluation of subexpressions is not defined. In
+ particular, subexpressions are not necessarily evaluated
+ left-to-right, right-to-left, or according to the lexical
+ precedence rules.
+
- The precedence and associativity of the operators is hard-wired
- into the parser. Most operators have the same precedence and are
- left-associative. This may lead to non-intuitive behavior; for
- example the Boolean operators < and > have a different
- precedence than the Boolean operators <= and >=. Also,
- you will sometimes need to add parentheses when using combinations
- of binary and unary operators. For instance
+ Furthermore, if the result of an expression can be determined by
+ evaluating only some parts of it, then some subexpressions
+ might not be evaluated at all. For instance, if one wrote
-SELECT 5 ! - 6;
+SELECT true OR somefunc();
- will be parsed as
+ then somefunc() would (probably) not be called
+ at all. The same would be the case if one wrote
-SELECT 5 ! (- 6);
+SELECT somefunc() OR true;
- because the parser has no idea -- until it is too late -- that
- ! is defined as a postfix operator, not an infix one.
- To get the desired behavior in this case, you must write
-SELECT (5 !) - 6;
-
- This is the price one pays for extensibility.
+ Note that this is not the same as the left-to-right
+ short-circuiting
of Boolean operators that is found
+ in some programming languages.
-
Operator Precedence (decreasing)
-
-
-
- |
- Operator/Element
- Associativity
- Description
-
-
-
-
- |
- .
- left
- table/column name separator
-
-
- |
- ::
- left
-
PostgreSQL-style typecast-
-
- |
- [ ]
- left
- array element selection
-
-
- |
- -
- right
- unary minus
-
-
- |
- ^
- left
- exponentiation
-
-
- |
- * / %
- left
- multiplication, division, modulo
-
-
- |
- + -
- left
- addition, subtraction
-
-
- |
- IS
-
- test for TRUE, FALSE, UNKNOWN, NULL
-
-
- |
- ISNULL
-
- test for NULL
-
-
- |
- NOTNULL
-
- test for NOT NULL
-
-
- |
- (any other)
- left
- all other native and user-defined operators
-
-
- |
- IN
-
- set membership
-
-
- |
- BETWEEN
-
- containment
-
-
- |
- OVERLAPS
-
- time interval overlap
-
-
- |
- LIKE ILIKE
-
- string pattern matching
-
-
- |
- < >
-
- less than, greater than
-
-
- |
- =
- right
- equality, assignment
-
-
- |
- NOT
- right
- logical negation
-
-
- |
- AND
- left
- logical conjunction
-
-
- |
- OR
- left
- logical disjunction
-
-
-
-
-
- Note that the operator precedence rules also apply to user-defined
- operators that have the same names as the built-in operators
- mentioned above. For example, if you define a
- +
operator for some custom data type it will have
- the same precedence as the built-in +
operator, no
- matter what yours does.
+ As a consequence, it is unwise to use functions with side effects
+ as part of complex expressions.
-
+
+
projects / postgresql.git / commitdiff