Cross-Product JOIN?

On 24/05/2023 10:22 CEST Atomic_Sheep <atomic.sheep@gmail.com> wrote:

"Finally, NATURAL is a shorthand form of USING: it forms a USING list
consisting of all column
names that appear in both input tables. As with USING, these columns
appear only once in the
output table. If there are no common column names, NATURAL JOIN
behaves like JOIN ...
ON TRUE, producing a cross-product join."

Did it mean cartesian product and not cross-product?

Cross product means cartesian product in this context. So technically correct.
Personally, I think it should read cartesian product because cross product is an
overloaded term and cartesian product is used more often in the documentation
overall.

But the same page [0]https://www.postgresql.org/docs/15/queries-table-expressions.html also uses cross product when talking about grouping sets.

The source code uses cross product in a couple of comments, though.

[0]: https://www.postgresql.org/docs/15/queries-table-expressions.html

--
Erik

On 24/05/2023 15:46 CEST Erik Wienhold <ewie@ewie.name> wrote:

Personally, I think it should read cartesian product because cross product is
an overloaded term and cartesian product is used more often in the documentation
overall.

But the same page [0] also uses cross product when talking about grouping sets.

[0] https://www.postgresql.org/docs/15/queries-table-expressions.html

Here's a patch that fixes those two places.

--
Erik

On Wed, 2023-05-24 at 21:10 +0200, Erik Wienhold wrote:

On 24/05/2023 15:46 CEST Erik Wienhold <ewie@ewie.name> wrote:

Personally, I think it should read cartesian product because cross product is
an overloaded term and cartesian product is used more often in the documentation
overall.

But the same page [0] also uses cross product when talking about grouping sets.

[0] https://www.postgresql.org/docs/15/queries-table-expressions.html

Here's a patch that fixes those two places.

+1

"Cross product" seems to be a misbegotten hybrid of "cross join" and
"Cartesian product".

Since we are talking about Cartesian products: is the term "Cartesian join"
used anywhere?

Yours,
Laurenz Albe

On 25/05/2023 06:52 CEST Laurenz Albe <laurenz.albe@cybertec.at> wrote:

On Wed, 2023-05-24 at 21:10 +0200, Erik Wienhold wrote:

On 24/05/2023 15:46 CEST Erik Wienhold <ewie@ewie.name> wrote:

Personally, I think it should read cartesian product because cross product is
an overloaded term and cartesian product is used more often in the documentation
overall.

But the same page [0] also uses cross product when talking about grouping sets.

[0] https://www.postgresql.org/docs/15/queries-table-expressions.html

Here's a patch that fixes those two places.

+1

"Cross product" seems to be a misbegotten hybrid of "cross join" and
"Cartesian product".

Cross product can mean Cartesian product depending on the context. [0]https://mathworld.wolfram.com/CartesianProduct.html

Since we are talking about Cartesian products: is the term "Cartesian join"
used anywhere?

Not in the docs:

$ git grep -iw cartesian -- doc
doc/src/sgml/cube.sgml: the lower-dimensional one is assumed to be a Cartesian projection, i. e., having zeroes
doc/src/sgml/perform.sgml: would be inefficient, since the full Cartesian product of A and C
doc/src/sgml/planstats.sgml: Cartesian product of the two inputs, multiplied by the
doc/src/sgml/queries.sgml: (that is, the Cartesian product of their rows is formed; see below).
doc/src/sgml/queries.sgml: <replaceable>T2</replaceable> (i.e., a Cartesian product),
doc/src/sgml/ref/select.sgml: specified, the result is the Cartesian product (cross join) of all
doc/src/sgml/ref/select.sgml: Cartesian product.
doc/src/sgml/ref/select.sgml: Cartesian product (i.e., all combined rows that pass its join
doc/src/sgml/ref/select.sgml: They produce a simple Cartesian product, the same result as you get from

but in a few comments:

$ git grep -i 'cartesian\(\s\+join\|\s*$\)'
src/backend/optimizer/geqo/geqo_eval.c: * a cartesian join to be performed. When force is false, do only
src/backend/optimizer/path/joinrels.c: * upper level, we must be willing to make a cartesian join of a and b;
src/backend/optimizer/path/joinrels.c: * cartesian joins in this case (no bushy).
src/test/regress/expected/join.out:-- test for ability to use a cartesian join when necessary
src/test/regress/sql/join.sql:-- test for ability to use a cartesian join when necessary

[0]: https://mathworld.wolfram.com/CartesianProduct.html

--
Erik

On Thu, 2023-05-25 at 08:59 +0200, Erik Wienhold wrote:

Since we are talking about Cartesian products: is the term "Cartesian join"
used anywhere?

Not in the docs:

I was trying to be funny. The Cartesian product of {Cartesian,cross} and
{product,join} would be {Cartesian product,Cartesian join,cross product,cross join}.

Yours,
Laurenz Albe

On 25/05/2023 23:46 CEST Laurenz Albe <laurenz.albe@cybertec.at> wrote:

On Thu, 2023-05-25 at 08:59 +0200, Erik Wienhold wrote:

Since we are talking about Cartesian products: is the term "Cartesian join"
used anywhere?

Not in the docs:

I was trying to be funny. The Cartesian product of {Cartesian,cross} and
{product,join} would be {Cartesian product,Cartesian join,cross product,cross join}.

And someone beat you to it and apparently planted the joke in the codebase.

(Good one, but unfortunately hard to tell apart from a serious question.)

--
Erik

On Wed, May 24, 2023 at 09:10:37PM +0200, Erik Wienhold wrote:

On 24/05/2023 15:46 CEST Erik Wienhold <ewie@ewie.name> wrote:

Personally, I think it should read cartesian product because cross product is
an overloaded term and cartesian product is used more often in the documentation
overall.

But the same page [0] also uses cross product when talking about grouping sets.

[0] https://www.postgresql.org/docs/15/queries-table-expressions.html

Here's a patch that fixes those two places.

Patch applied to master, thanks.

--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com

Only you can decide what is important to you.