SQL 标准是否允许函数名和括号之间有空格
检查了几个 RDBMS,我发现类似的事情
SELECT COUNT (a), SUM (b)
FROM TABLE
是允许的(注意聚合函数和括号之间的空格)。
谁能提供一个指向 SQL 标准本身定义的指针(任何版本都可以)?
编辑: 上述工作在postgres中,mysql需要set sql_mode = "IGNORE_SPACE";
按照定义此处(有关受此服务器模式影响的函数的完整列表,请参阅 此 参考)。 据报道,MS SQL 接受上述内容。
另外,答案似乎最有可能在 标准< /a>.我可以遵循 BNF 关于常规符号和术语,但我当涉及到该选择部分中的空白和分隔符的定义时,会迷失方向。
Checking few RDBMS I find that things like
SELECT COUNT (a), SUM (b)
FROM TABLE
are allowed (notice space between aggregate functions and parenthesis).
Could anyone provide a pointer to SQL standard itself where this is defined (any version will do)?
EDIT:
The above works in postgres, mysql needs set sql_mode = "IGNORE_SPACE";
as defined here (for full list of functions that are influenced with this server mode see in this ref).
MS SQL is reported to accept the above.
Also, it seems that the answer is most likely in the standard. I can follow the BNF regarding the regular symbols and terms, but I get lost when it comes to the definition of whitespace and separators in that part of the select.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
是的;标记之间的空白基本上被忽略。唯一的例外是,正式而言,相邻字符串文字连接 - 但该标准比任何实现都更奇怪。
请参阅:http://savage.net.au/SQL/
Yes; the white space between tokens is substantially ignored. The only exception is, officially, with adjacent string literal concatenation - but the standard is weirder than any implementation would be.
See: http://savage.net.au/SQL/
这在 SQL Server 2005 中有效:
...而 MySQL 上的
COUNT
和(*)
之间的一个空格会导致 MySQL 1064 错误(语法错误)。我没有方便测试的 Oracle 或 Postgres。无论标准是什么,它都取决于供应商的实现和您正在使用的版本。
This works in SQL Server 2005:
...while one space between
COUNT
and(*)
on MySQL causes a MySQL 1064 error (syntax error). I don't have Oracle or Postgres handy to test.Whatever the standard may be, it's dependent on implementation in the vendor and version you are using.
我无法提供指针,但我相信这样的空白会被忽略。
我知道它是在 T-SQL 中,并且对 MySQL 的实现有大约 80% 的把握。
I can't provide a pointer, but I believe that white space like that is ignored.
I know that it is in T-SQL, and about 80% certain about MySQL's implementation.