我试图通过两个set-returns函数得到一个“交叉连接”，但在某些情况下我没有得到“交叉连接”，参见示例
行为1：当设置的长度相同时，它会逐个匹配每个集合
postgres=# SELECT generate_series(1,3), generate_series(5,7) order by 1,2;
generate_series | generate_series
-----------------+-----------------
1 | 5
2 | 6
3 | 7
(3 rows)
行为2：当设定长度不同时，它会“交叉连接”这些集合
postgres=# SELECT generate_series(1,2), generate_series(5,7) order by 1,2;
generate_series | generate_series
-----------------+-----------------
1 | 5
1 | 6
1 | 7
2 | 5
2 | 6
2 | 7
(6 rows)
我想我在这里不了解某些事情，有人可以解释预期的行为吗？
另一个例子，甚至更奇怪：
postgres=# SELECT generate_series(1,2) x, generate_series(1,4) y order by x,y; x | y ---+--- 1 | 1 1 | 3 2 | 2 2 | 4 (4 rows)
我正在寻找标题中问题的答案，理想情况是链接到文档。
为较小的集添加空值。与generate_series()演示：
SELECT generate_series( 1, 2) AS row2
, generate_series(11, 13) AS row3
, generate_series(21, 24) AS row4;
row2 | row3 | row4 -----+------+----- 1 | 11 | 21 2 | 12 | 22 null | 13 | 23 null | null | 24
dbfiddle here
如果查询的选择列表中有多个set-returns函数，则行为类似于将函数放入单个
LATERAL ROWS FROM( ... )FROM子句项中所获得的行为。对于基础查询中的每一行，都有一个输出行，使用每个函数的第一个结果，然后是使用第二个结果的输出行，依此类推。如果某些set-returns函数产生的输出少于其他函数，则将null值替换为缺失数据，以便为一个底层行发出的总行数与生成最多输出的set-returns函数相同。因此，set-returns函数以“锁步”方式运行，直到它们全部耗尽，然后继续执行下一个底层行。
这结束了传统上奇怪的行为。
结果行的数量（有点令人惊讶！）是同一个SELECT列表中所有集合的最低公倍数。 （如果所有的大小都没有公约数，那么就像CROSS JOIN一样！）演示：
SELECT generate_series( 1, 2) AS row2
, generate_series(11, 13) AS row3
, generate_series(21, 24) AS row4;
row2 | row3 | row4 -----+------+----- 1 | 11 | 21 2 | 12 | 22 1 | 13 | 23 2 | 11 | 24 1 | 12 | 21 2 | 13 | 22 1 | 11 | 23 2 | 12 | 24 1 | 13 | 21 2 | 11 | 22 1 | 12 | 23 2 | 13 | 24
dbfiddle here
在manual for Postgres 9.6 the chapter SQL Functions Returning Sets记录，以及避免它的建议：
注意：在选择列表中使用set-returns函数而不是
FROM子句的关键问题是在同一个选择列表中放置多个set-returns函数的行为不是很明智。 （如果这样做，实际得到的是一些输出行，它们等于每个set-returns函数产生的行数的最小公倍数。）当调用多个set-returns函数时，LATERAL语法产生的结果不那么令人惊讶，通常应该使用。
大胆强调我的。
单个集返回函数是正常的（但在FROM列表中仍然更清晰），但现在不鼓励使用相同的SELECT列表中的多个。在我们加入LATERAL之前，这是一个有用的功能。现在它只是历史的镇流器。
有关：
我找不到任何相关的文档。但是，我可以描述我观察到的行为。
集合生成函数每个返回有限数量的行。 Postgres似乎运行set生成函数，直到所有这些函数都在最后一行 - 或者，当所有函数都回到第一行时更有可能停止。从技术上讲，这将是系列长度的最小公倍数（LCM）。
我不确定为什么会这样。而且，正如我在评论中所说，我认为通常将函数放在from子句中会更好。
关于the documentation问题的唯一注意事项。我不确定这是否解释了所描述的行为。也许更重要的是不推荐使用这样的函数：
目前，还可以在查询的选择列表中调用返回集的函数。对于查询自身生成的每一行，将调用函数返回集，并为函数结果集的每个元素生成输出行。但请注意，此功能已弃用，可能会在将来的版本中删除。