PostgreSQL数据库Dig8

1. 操作符（Operators）

操作符的名称可以由下列字符组成，其最大长度为NAMEDATALEN-1 (默认63)：

+ - * /< > = ~ ! @ # % ^ & | ‘ ?

对于操作符的名称有以下的限制：

--和/*不能出现在操作符名称的任何位置，因为这将会被当做是注释内容的开始
一个多字符的操作符不能够以+或者-结束，除非这个操作符名称中还包含至少以下字符中的一个：
~ ! @ # % ^ & | ‘ ?

例如：

 @- 是一个合法的操作符名称而 *- 则不是

这种限制使得PostgreSQL能够在标记没有空格分割的情况下分析符合SQL的查询 。当使用非SQL标准的操作符名称时，我们通常为了使意思清除需要将紧接着的操作符用空格进行分割，例如，如果你已经定义了一个左一元操作符名称@ ，你就不能再写 X*@Y，而需要写X* @Y来保证PostgreSQL将它视为两个操作符名称而不是一个。

2. 特殊字符（Special Characters）

一些未包含数字或者字母的字符在不作为操作符时具有特殊的含义，关于这些的详细使用可以在各自的语法元素中读取到，本部分只是提醒一下这些用法的差别以及总结一下这些字符的用途

一个美元符号 (\$) 和紧跟着的数字经常被用来代表一个在函数体中或者期望陈述/声明中de 位置参数 。在其他的语境中美元符号可以作为一个标识符的一部分或者\$引用字符串常量

圆括号 (())通常是用来将表达式进行分组或者指定有限级。在一些情况下，圆括号是作为特殊SQL命令修正语法的一部分

中括号 ([]) 是用来选择数组中的元素的

逗号(,) 被用在一些语法结构中作为一列元素的分割符

分号 (;) 是作为SQL命令的结束标志，它不能出现在SQL命令中的任何位置，除了字符串常量或者引用标识符

冒号(:)用来从数组中选择分片 

星号(*)被用在一些文本中来代表一个数据表中的所有域，在作为统计函数的参数时它还有特殊的含义，即统计函数不需要任何明确的参数

句号 (.)通常用在数字常量中，被用来分割数据库对象集合、数据表、和列名称

3. 注释（Comments）

注释是以一对短线/破折号开始的一个字符序列，并且延伸到行尾，e.g.:

-- This is a standard SQL comment

而且，C-style的块注释也可以被使用:

/*multiline comment
*with nesting: /*nested block comment
*/*/

注释由/*开始一直延伸到匹配的结束标志*/
这些注释块嵌套在一起，在SQL标准中并不像C, 所以我们能够在一大块注释中找到另外一块注释。注释块会在进一步的语法分析中被从输入流中移除，并且由空格进行替代。

4. 操作符的优先级（Operator Precedence）

大多数操作符拥有相同的优先级并且都是左结合的，有时候我们需要通过小括号来改变优先级或者对操作符进行分块：

SELECT 5 ! - 6;

SELECT 5 ! (- 6);

SELECT (5 !) - 6;

操作符优先级表(由高到低）

对于用户自定的操作符上表同样适用，

以下内容为拓展不翻译
Note:

    PostgreSQL versions before 9.5 used slightly different operator precedence rules. In particular,<=>=and<>used to be treated as generic operators;IS tests used to have higher priority;and NOT BETWEEN and related constructs acted inconsistently, being taken in some cases as having the precedence of NOT rather than BETWEEN. These rules were changed for better compliancewith the SQL standard and to reduce confusion from inconsistent treatment of logically equivalentconstructs. In most cases, these changes will result in no behavioral change, or perhaps in “nosuch operator” failures which can be resolved by adding parentheses. However there are corner cases in which a query might change behavior without any parsing error being reported. If you are concerned about whether these changes have silently broken something, you can test your application with the configuration parameter operator_precedence_warning turned on to see ifany warnings are logged.