当前位置： >
left join 和 left outer join 的区别
时间： 11:21
作者:滴答的水
left join 和 left outer join 的区别
通俗的讲：
A left join B 的连接的记录数与A表的记录数同
A right join B 的连接的记录数与B表的记录数同
A left join B 等价B right join A
table A: Field_K, Field_A
Field_K, Field_B
select a.Field_K, a.Field_A, b.Field_K, b.Field_B
from a left join b on a.Field_K=b.Field_K
Field_K Field_A Field_K Field_B
---------- ---------- ---------- ----------
3 b NULL NULL
select a.Field_K, a.Field_A, b.Field_K, b.Field_B
from a right join b on a.Field_K=b.Field_K
Field_K Field_A Field_K Field_B
---------- ---------- ---------- ----------
NULL NULL 2 y
4 c 4 z --
举个例子：
假设ａ表和ｂ表的数据是这样的。
id name　　id stock　
1　　a 1 15
select * from a inner join b on a.id=b.id
这个语法是连接查询中的内连接，它产生的结果是
两个表相匹配的记录出现在结果列表中。
根据上面的表，出现的结果是这样的
a.id name b.id stock
1　　 a 1 15
----------------------------
select * from a,b where a.id=b.id
这个语法是内连接的另外一种写法，其执行结果与inner join 一样
--------------------------------
select * from a left/right join b on a.id=b.id
这个是外连接语法中的左外连接或右外连接
如果是左外连接的话，它将显示ａ表的所有记录，
select a.*,b.* from a left join b on a.id=b.id
查询的结果是这样的：
a.id name b.id stock
1　　 a 1 15
3 c null null　
--------------------------------------------
如果是右外连接的话，它将显示ｂ表的所有记录，
select a.*,b.* from a right join b on a.id=b.id
查询的结果是这样的：
a.id name b.id stock
1　　 a 1 15
select a.*,b.* from a left join b on a.k = b.k
select a.*,b.* from a left outer join b on a.k =b.k
----------上面两种一样left join是left outer join的简写
select a.*,b.* from a left inner join b on a.k = b.k
没有这种写法，错误的语句.
在你要使用多个left join的时候
比如说10个
我们把10个全都写成left join的形式
然后再SQL让他自动运行一下，它会把最后一次出现的left join变成left outer join
所以依此推理，最后一个left join会以left outer join的形式存在
当然，不管变不变对结果的显示没有任何影响
希望我的实验能对你有所帮助
使用关系代数合并数据 1 关系代数 合并数据集合的理论基础是关系代数，它是由E.F.Codd于1970年提出的。 在关系代数的形式化语言中： ? 用表、或者数据集合表示关系或者实体。 ? 用行表示元组。 ? 用列表示属性。 关系代数包含以下8个关系运算符 ? 选取DD返回满足指定条件的行。 ? 投影DD从数据集合中返回指定的列。 ? 笛卡尔积DD是关系的乘法，它将分别来自两个数据集合中的行以所有可能的方式进行组合。 ? 并DD关系的加法和减法，它可以在行的方向上合并两个表中的数据，就像把一个表垒在另一个表之上一样。 ? 交DD返回两个数据集合所共有的行。 ? 差DD返回只属于一个数据集合的行。 ? 连接DD在水平方向上合并两个表，其方法是：将两个表中在共同数据项上相互匹配的那些行合并起来。 ? 除DD返回两个数据集之间的精确匹配。 此外，作为一种实现现代关系代数运算的方法，SQL还提供了： ? 子查询DD类似于连接，但更灵活；在外部查询中，方式可以使用表达式、列表或者数据集合的地方都可以使用子查询的结果。 本章将主要讲述多种类型的连接、简单的和相关的子查询、几种类型的并、关系除以及其他的内容。 2 使用连接 2.1 连接类型 在关系代数中，连接运算是由一个笛卡尔积运算和一个选取运算构成的。首先用笛卡尔积完成对两个数据集合的乘运算，然后对生成的结果集合进行选取运算，确保只把分别来自两个数据集合并且具有重叠部分的行合并在一起。连接的全部意义在于在水平方向上合并两个数据集合（通常是表），并产生一个新的结果集合，其方法是将一个数据源中的行于另一个数据源中和它匹配的行组合成一个新元组。 SQL提供了多种类型的连接方式，它们之间的区别在于：从相互交叠的不同数据集合中选择用于连接的行时所采用的方法不同。 连接类型 定义 内连接 只连接匹配的行 左外连接 包含左边表的全部行（不管右边的表中是否存在与它们匹配的行），以及右边表中全部匹配的行 右外连接 包含右边表的全部行（不管左边的表中是否存在与它们匹配的行），以及左边表中全部匹配的行 全外连接 包含左、右两个表的全部行，不管另外一边的表中是否存在与它们匹配的行。 (H)(theta)连接 使用等值以外的条件来匹配左、右两个表中的行 交叉连接 生成笛卡尔积－它不使用任何匹配或者选取条件，而是直接将一个数据源中的每个行与另一个数据源的每个行都一一匹配 在INFORMIX中连接表的查询 如果FROM子句指定了多于一个表引用，则查询会连接来自多个表的行。连接条件指定各列之间（每个表至少一列）进行连接的关系。因为正在比较连接条件中的列，所以它们必须具有一致的数据类型。 SELECT语句的FROM子句可以指定以下几种类型的连接 FROM子句关键字 相应的结果集 CROSS JOIN 笛卡尔乘积（所有可能的行对） INNER JOIN 仅对满足连接条件的CROSS中的列 LEFT OUTER JOIN 一个表满足条件的行，和另一个表的所有行 RIGHT OUTER JOIN 与LEFT相同，但两个表的角色互换 FULL OUTER JOIN LEFT OUTER 和 RIGHT OUTER中所有行的超集
下一篇：没有了怎么用left outer join 优化以下的NOT Exists语名，急。。。谢谢！_百度知道
怎么用left outer join 优化以下的NOT Exists语名，急。。。谢谢！
SELECT DISTINCT Z1.BILLTYPEID,Z1.BILLNUMBER FROM (
SELECT D.ORDERFORM_MID,D.BILLIT,D.BILLTYPEID,D.BILLNUMBER,D.BILLDATE,D.Flag,D.DeptCode_ FROM WorkFlowLog AS D
WHERE NOT Exists (Select ORDERFORM_MID,BILLIT,BILLTYPEID,BILLNUMBER,BILLDATE,Flag,Dep旦触测吠爻杜诧森超缉tCode_ FROM WorkFlowLog AS E
WHERE D.ORDERFORM_MID=E.ORDERFORM_MID AND D.BILLTYPEID=E.BILLTYPEID AND D.BILLNUMBER=E.BILLNUMBER AND D.BILLIT&E.BILLIT
AND coalesce(D.DeptCode_,'')=coalesce(E.DeptCode_,'') )
AND coalesce(D.Type_,'')&&'comfirm'
WHERE coalesce(Type_,'') &&'SendMail' AND Trim(STATUS_)='1') AS ZON Z1.BILLTYPEID=Z.TB_ AND coalesce(Z1.Flag,0)=coalesce(Z.Level_,0)-1 AND coalesce(Z.DeptCode_,'')=coalesce(Z1.DeptCode_,'') AND coalesce(Z.Type_,'') NOT IN ('SendMail') AND Z.EmployeeID_=';) AS Z2 Group By Z2.BILLTYPEID) AS Z5 LEFT OUTER JOIN Tmenulist AS Z6 ON Z5.BILL旦触测吠爻杜诧森超缉TYPEID=Z6.FormIDORDER BY Z5.BILLTYPEID
提问者采纳
SELECT&DISTINCT&Z1.BILLTYPEID,&Z1.BILLNUMBER&&FROM&(SELECT&D.ORDERFORM_MID,&&&&&&&&nbs旦触测吠爻杜诧森超缉p;&&&&&&&D.BILLIT,&&&&&&&&&&&&&&&D.BILLTYPEID,&&&&&&&&&&&&&&&D.BILLNUMBER,&&&&&&&&&&&&&&&D.BILLDATE,&&&&&&&&&&&&&&&D.Flag,&&&&&&&&&&&&&&&D.DeptCode_&&&&&&&&&&FROM&WorkFlowLog&AS&D&&&&&&&&&&LEFT&JOIN&WorkFlowLog&AS&E&&&&&&&&&&&&ON&D.ORDERFORM_MID&=&E.ORDERFORM_MID&&&&&&&&&&&AND&D.BILLTYPEID&=&E.BILLTYPEID&&&&&&&&&&&AND&D.BILLNUMBER&=&E.BILLNUMBER&&&&&&&&&&&AND&D.BILLIT&&&E.BILLIT&&&&&&&&&&&AND&coalesce(D.DeptCode_,&'')&=&coalesce(E.DeptCode_,&'')&&&&&&&&&&&AND&coalesce(D.Type_,&'')&&&&'comfirm'&&&&&&&&&WHERE&E.ORDERFORM_MID&IS&NULL)&AS&Z1
您好，谢谢你的回答，但查询出来的结果不对，这个是根据相同的ORDERFORM_MID,D.BILLIT,D.BILLTYPEID,D.BILLNUMBER, D.BILLDATE, D.Flag,D.DeptCode_查出BILLIT（最大序）的行。其实我的原SQL是下面这样子的，查询出来速度有点慢，我想把它优化一下，谢谢！原SQL在下面的评论，因为太长了，这里写不了，谢谢！
提问者评价
来自团队：MySQL 5.5 Reference Manual :: 13.2.9.2 JOIN Syntax
MySQL 5.5 Manual
Section Navigation &&&&&[]
13.2.9.2 JOIN Syntax
MySQL supports the following JOIN syntaxes
for the table_references part of
statements and
multiple-table
statements:
table_references:
escaped_table_reference [, escaped_table_reference] ...
escaped_table_reference:
table_reference
| { OJ table_reference }
table_reference:
table_factor
| join_table
table_factor:
tbl_name [[AS] alias] [index_hint_list]
| table_subquery [AS] alias
| ( table_references )
join_table:
table_reference [INNER | CROSS] JOIN table_factor [join_condition]
| table_reference STRAIGHT_JOIN table_factor
| table_reference STRAIGHT_JOIN table_factor ON conditional_expr
| table_reference {LEFT|RIGHT} [OUTER] JOIN table_reference join_condition
| table_reference NATURAL [{LEFT|RIGHT} [OUTER]] JOIN table_factor
join_condition:
ON conditional_expr
| USING (column_list)
index_hint_list:
index_hint [, index_hint] ...
index_hint:
USE {INDEX|KEY}
[FOR {JOIN|ORDER BY|GROUP BY}] ([index_list])
| IGNORE {INDEX|KEY}
[FOR {JOIN|ORDER BY|GROUP BY}] (index_list)
| FORCE {INDEX|KEY}
[FOR {JOIN|ORDER BY|GROUP BY}] (index_list)
index_list:
index_name [, index_name] ...
A table reference is also known as a join expression.
The syntax of table_factor is
extended in comparison with the SQL Standard. The latter accepts
only table_reference, not a list of
them inside a pair of parentheses.
This is a conservative extension if we consider each comma in a
list of table_reference items as
equivalent to an inner join. For example:
SELECT * FROM t1 LEFT JOIN (t2, t3, t4)
ON (t2.a=t1.a AND t3.b=t1.b AND t4.c=t1.c)
is equivalent to:
SELECT * FROM t1 LEFT JOIN (t2 CROSS JOIN t3 CROSS JOIN t4)
ON (t2.a=t1.a AND t3.b=t1.b AND t4.c=t1.c)
In MySQL, JOIN, CROSS
JOIN, and INNER JOIN are syntactic
equivalents (they can replace each other). In standard SQL, they
are not equivalent. INNER JOIN is used with
an ON clause, CROSS JOIN
is used otherwise.
In general, parentheses can be ignored in join expressions
containing only inner join operations. MySQL also supports
nested joins (see ).
Index hints can be specified to affect how the MySQL optimizer
makes use of indexes. For more information, see
The following list describes general factors to take into
account when writing joins.
A table reference can be aliased using
tbl_name AS
alias_name or
tbl_name alias_name:
SELECT t1.name, t2.salary
FROM employee AS t1 INNER JOIN info AS t2 ON t1.name = t2.
SELECT t1.name, t2.salary
FROM employee t1 INNER JOIN info t2 ON t1.name = t2.
A table_subquery is also known as
a subquery in the FROM clause. Such
subqueries must include an alias to
give the subquery result a table name. A trivial example
see also .
SELECT * FROM (SELECT 1, 2, 3) AS t1;
INNER JOIN and ,
(comma) are semantically equivalent in the absence of a join
condition: both produce a Cartesian product between the
specified tables (that is, each and every row in the first
table is joined to each and every row in the second table).
However, the precedence of the comma operator is less than
of INNER JOIN, CROSS
JOIN, LEFT JOIN, and so on. If
you mix comma joins with the other join types when there is
a join condition, an error of the form Unknown
column 'col_name' in 'on
clause' may occur. Information about dealing with
this problem is given later in this section.
The conditional_expr used with
ON is any conditional expression of the
form that can be used in a WHERE clause.
Generally, you should use the ON clause
for conditions that specify how to join tables, and the
WHERE clause to restrict which rows you
want in the result set.
If there is no matching row for the right table in the
ON or USING part in a
LEFT JOIN, a row with all columns set to
NULL is used for the right table. You can
use this fact to find rows in a table that have no
counterpart in another table:
SELECT left_tbl.*
FROM left_tbl LEFT JOIN right_tbl ON left_tbl.id = right_tbl.id
WHERE right_tbl.id IS NULL;
This example finds all rows in left_tbl
with an id value that is not present in
right_tbl (that is, all rows in
left_tbl with no corresponding row in
right_tbl). This assumes that
right_tbl.id is declared NOT
USING(column_list)
clause names a list of columns that must exist in both
tables. If tables a and
b both contain columns
c1, c2, and
c3, the following join compares
corresponding columns from the two tables:
a LEFT JOIN b USING (c1,c2,c3)
The NATURAL [LEFT] JOIN of two tables is
defined to be semantically equivalent to an INNER
JOIN or a LEFT JOIN with a
USING clause that names all columns that
exist in both tables.
RIGHT JOIN works analogously to
LEFT JOIN. To keep code portable across
databases, it is recommended that you use LEFT
JOIN instead of RIGHT JOIN.
The { OJ ... } syntax shown in the join
syntax description exists only for compatibility with ODBC.
The curly braces in the syntax should
they are not metasyntax as used elsewhere in syntax
descriptions.
SELECT left_tbl.*
FROM { OJ left_tbl LEFT OUTER JOIN right_tbl ON left_tbl.id = right_tbl.id }
WHERE right_tbl.id IS NULL;
You can use other types of joins within { OJ ...
}, such as INNER JOIN or
RIGHT OUTER JOIN. This helps with
compatibility with some third-party applications, but is not
official ODBC syntax.
The parser does not permit nested { OJ ...
} constructs (which are not legal ODBC syntax,
anyway). Queries that use such constructs should be
rewritten. For an example, see
STRAIGHT_JOIN is similar to
JOIN, except that the left table is
always read before the right table. This can be used for
those (few) cases for which the join optimizer puts the
tables in the wrong order.
Some join examples:
SELECT * FROM table1, table2;
SELECT * FROM table1 INNER JOIN table2 ON table1.id=table2.
SELECT * FROM table1 LEFT JOIN table2 ON table1.id=table2.
SELECT * FROM table1 LEFT JOIN table2 USING (id);
SELECT * FROM table1 LEFT JOIN table2 ON table1.id=table2.id
LEFT JOIN table3 ON table2.id=table3.
Join Processing Changes in MySQL
Natural joins and joins with USING,
including outer join variants, are processed according to the
SQL:2003 standard. The goal was to align the syntax and
semantics of MySQL with respect to NATURAL
JOIN and JOIN ... USING according
to SQL:2003. However, these changes in join processing can
result in different output columns for some joins. Also, some
queries that appeared to work correctly in older versions
(prior to 5.0.12) must be rewritten to comply with the
These changes have five main aspects:
The way that MySQL determines the result columns of
NATURAL or USING join
operations (and thus the result of the entire
FROM clause).
Expansion of SELECT * and SELECT
tbl_name.* into a list
of selected columns.
Resolution of column names in NATURAL or
USING joins.
Transformation of NATURAL or
USING joins into JOIN ...
Resolution of column names in the ON
condition of a JOIN ... ON.
The following list provides more detail about several effects of
current join processing versus join processing in older
versions. The term “previously” means “prior
to MySQL 5.0.12.”
The columns of a NATURAL join or a
USING join may be different from
previously. Specifically, redundant output columns no longer
appear, and the order of columns for SELECT
* expansion may be different from before.
Consider this set of statements:
CREATE TABLE t1 (i INT, j INT);
CREATE TABLE t2 (k INT, j INT);
INSERT INTO t1 VALUES(1,1);
INSERT INTO t2 VALUES(1,1);
SELECT * FROM t1 NATURAL JOIN t2;
SELECT * FROM t1 JOIN t2 USING (j);
Previously, the statements produced this output:
+------+------+------+------+
+------+------+------+------+
+------+------+------+------+
+------+------+------+------+
+------+------+------+------+
+------+------+------+------+
In the first
statement, column j appears in both
tables and thus becomes a join column, so, according to
standard SQL, it should appear only once in the output, not
twice. Similarly, in the second SELECT statement, column
j is named in the
USING clause and should appear only once
in the output, not twice. But in both cases, the redundant
column is not eliminated. Also, the order of the columns is
not correct according to standard SQL.
Now the statements produce this output:
+------+------+------+
+------+------+------+
+------+------+------+
+------+------+------+
+------+------+------+
+------+------+------+
The redundant column is eliminated and the column order is
correct according to standard SQL:
First, coalesced common columns of the two joined
tables, in the order in which they occur in the first
Second, columns unique to the first table, in order in
which they occur in that table
Third, columns unique to the second table, in order in
which they occur in that table
The single result column that replaces two common columns is
defined using the coalesce operation. That is, for two
t1.a and t2.a the
resulting single join column a is defined
as a = COALESCE(t1.a, t2.a), where:
COALESCE(x, y) = (CASE WHEN V1 IS NOT NULL THEN V1 ELSE V2 END)
If the join operation is any other join, the result columns
of the join consists of the concatenation of all columns of
the joined tables. This is the same as previously.
A consequence of the definition of coalesced columns is
that, for outer joins, the coalesced column contains the
value of the non-NULL column if one of
the two columns is always NULL. If
neither or both columns are NULL, both
common columns have the same value, so it doesn't matter
which one is chosen as the value of the coalesced column. A
simple way to interpret this is to consider that a coalesced
column of an outer join is represented by the common column
of the inner table of a JOIN. Suppose
that the tables t1(a,b) and
t2(a,c) have the following contents:
mysql& SELECT * FROM t1 NATURAL LEFT JOIN t2;
+------+------+------+
+------+------+------+
+------+------+------+
Here column a contains the values of
mysql& SELECT * FROM t1 NATURAL RIGHT JOIN t2;
+------+------+------+
+------+------+------+
+------+------+------+
Here column a contains the values of
Compare these results to the otherwise equivalent queries
with JOIN ... ON:
mysql& SELECT * FROM t1 LEFT JOIN t2 ON (t1.a = t2.a);
+------+------+------+------+
+------+------+------+------+
| NULL | NULL |
+------+------+------+------+
mysql& SELECT * FROM t1 RIGHT JOIN t2 ON (t1.a = t2.a);
+------+------+------+------+
+------+------+------+------+
| NULL | NULL |
+------+------+------+------+
Previously, a USING clause could be
rewritten as an ON clause that compares
corresponding columns. For example, the following two
clauses were semantically identical:
a LEFT JOIN b USING (c1,c2,c3)
a LEFT JOIN b ON a.c1=b.c1 AND a.c2=b.c2 AND a.c3=b.c3
Now the two clauses no longer are quite the same:
With respect to determining which rows satisfy the join
condition, both joins remain semantically identical.
With respect to determining which columns to display for
SELECT * expansion, the two joins are
not semantically identical. The USING
join selects the coalesced value of corresponding
columns, whereas the ON join selects
all columns from all tables. For the preceding
USING join, SELECT
* selects these values:
COALESCE(a.c1,b.c1), COALESCE(a.c2,b.c2), COALESCE(a.c3,b.c3)
For the ON join, SELECT
* selects these values:
a.c1, a.c2, a.c3, b.c1, b.c2, b.c3
With an inner join,
the same as either a.c1 or
b.c1 because both columns will have
the same value. With an outer join (such as
LEFT JOIN), one of the two columns
can be NULL. That column will be
omitted from the result.
The evaluation of multi-way natural joins differs in a very
important way that affects the result of
NATURAL or USING joins
and that can require query rewriting. Suppose that you have
three tables t1(a,b),
t2(c,b), and t3(a,c)
that each have one row: t1(1,2),
t2(10,2), and
t3(7,10). Suppose also that you have this
NATURAL JOIN on the three tables:
SELECT ... FROM t1 NATURAL JOIN t2 NATURAL JOIN t3;
Previously, the left operand of the second join was
considered to be t2, whereas it should be
the nested join (t1 NATURAL JOIN t2). As
a result, the columns of t3 are checked
for common columns only in t2, and, if
t3 has common columns with
t1, these columns are not used as
equi-join columns. Thus, previously, the preceding query was
transformed to the following equi-join:
SELECT ... FROM t1, t2, t3
WHERE t1.b = t2.b AND t2.c = t3.c;
That join is missing one more equi-join predicate
(t1.a = t3.a). As a result, it produces
one row, not the empty result that it should. The correct
equivalent query is this:
SELECT ... FROM t1, t2, t3
WHERE t1.b = t2.b AND t2.c = t3.c AND t1.a = t3.a;
If you require the same query result in current versions of
MySQL as in older versions, rewrite the natural join as the
first equi-join.
Previously, the comma operator (,) and
JOIN both had the same precedence, so the
join expression t1, t2 JOIN t3 was
interpreted as ((t1, t2) JOIN t3). Now
JOIN has higher precedence, so the
expression is interpreted as (t1, (t2 JOIN
t3)). This change affects statements that use an
ON clause, because that clause can refer
only to columns in the operands of the join, and the change
in precedence changes interpretation of what those operands
CREATE TABLE t1 (i1 INT, j1 INT);
CREATE TABLE t2 (i2 INT, j2 INT);
CREATE TABLE t3 (i3 INT, j3 INT);
INSERT INTO t1 VALUES(1,1);
INSERT INTO t2 VALUES(1,1);
INSERT INTO t3 VALUES(1,1);
SELECT * FROM t1, t2 JOIN t3 ON (t1.i1 = t3.i3);
Previously, the
legal due to the implicit grouping of
t1,t2 as (t1,t2). Now
the JOIN takes precedence, so the
operands for the ON clause are
t2 and t3. Because
t1.i1 is not a column in either of the
operands, the result is an Unknown column 't1.i1'
in 'on clause' error. To allow the join to be
processed, group the first two tables explicitly with
parentheses so that the operands for the
ON clause are (t1,t2)
SELECT * FROM (t1, t2) JOIN t3 ON (t1.i1 = t3.i3);
Alternatively, avoid the use of the comma operator and use
JOIN instead:
SELECT * FROM t1 JOIN t2 JOIN t3 ON (t1.i1 = t3.i3);
This change also applies to statements that mix the comma
operator with INNER JOIN, CROSS
JOIN, LEFT JOIN, and
RIGHT JOIN, all of which now have higher
precedence than the comma operator.
Previously, the ON clause could refer to
columns in tables named to its right. Now an
ON clause can refer only to its operands.
CREATE TABLE t1 (i1 INT);
CREATE TABLE t2 (i2 INT);
CREATE TABLE t3 (i3 INT);
SELECT * FROM t1 JOIN t2 ON (i1 = i3) JOIN t3;
Previously, the
statement was legal. Now the statement fails with an
Unknown column 'i3' in 'on clause' error
because i3 is a column in
t3, which is not an operand of the
ON clause. The statement should be
rewritten as follows:
SELECT * FROM t1 JOIN t2 JOIN t3 ON (i1 = i3);
Resolution of column names in NATURAL or
USING joins is different than previously.
For column names that are outside the
FROM clause, MySQL now handles a superset
of the queries compared to previously. That is, in cases
when MySQL formerly issued an error that some column is
ambiguous, the query now is handled correctly. This is due
to the fact that MySQL now treats the common columns of
NATURAL or USING joins
as a single column, so when a query refers to such columns,
the query compiler does not consider them as ambiguous.
SELECT * FROM t1 NATURAL JOIN t2 WHERE b & 1;
Previously, this query would produce an error ERROR
): Column 'b' in where clause is
ambiguous. Now the query produces the correct
+------+------+------+
+------+------+------+
+------+------+------+
One extension of MySQL compared to the SQL:2003 standard is
that MySQL enables you to qualify the common (coalesced)
columns of NATURAL or
USING joins (just as previously), while
the standard disallows that.}