Database Reference
In-Depth Information
A Note on “Standard” SQL
Many people refer to the SQL standard as if it was a single,
uncontroversial document. As a comparison, the HTTP protocol, which
is used whenever you navigate to a web page, is defined in RFC 2616. It
has been implemented dozens of times by web severs and web
browsers. The fact that you can usually switch from Firefox to Safari
without much hassle is a testament to the clarity and widespread
implementation of the HTTP standard.
The SQL standard, however, can mean a lot of different things. For
example, there are SQL-92, SQL-99, SQL-2003, SQL-2006, and more.
Moreover, most database implementations pick and choose from the
various SQL standards and may lack basic features from any standard
version. For example, Oracle doesn't have a TIME type, and few people
care about the XML-based features that were added in the XML-mad
days when the SQL-2003 specification was defined.
One of the biggest difficulties with the specification of SQL is that all
vendors had ways that they wanted to extend what was possible to do in
SQL. They may have proceeded with an implementation before there
was a specification. Another vendor may have added a similar feature a
different way. That feature, then, becomes difficult to standardize
because there are competing implementations, and backward
compatibility can become problematic.
BigQuery has a number of features for which no standards exist, such
as support for nested and repeated fields. In these cases, BigQuery
diverges from the standard SQL because the features aren't in the
standard but were considered important to the product.
There are also a number of potentially painful cases where BigQuery
diverges from the SQL standard. The syntax for table union is an
example of this: To make it easy to query multiple tables at once, the
comma operator was used to indicate UNION ALL . This decision
confuses many people because a comma-separated list of tables usually
indicates a JOIN operation.
Search WWH ::




Custom Search