Oleg is saying that the optimizer doesn't protect against foolish SQL requests. His query is an example of a foolishly written query.
IMHO calling this a "foolishly written query" is completely arbitrary. I can imagine plenty of applications for which a cartesian join makes sense. In this case the user didn't write the query they meant to write -- but it is surely hopeless to prevent that in the general case :)
It seems a reasonable that there might be a GUC such as enable_cartesian = on (by default)
I think the bar for adding a new GUC ought to be significantly higher than that.
In any case, when this problem does occur, it is obvious to the user that something is wrong, and no harm is done. Given a complex SQL query, it might take a bit of examination to determine which join clause is missing -- but the proper way to fix that is better query visualization tools (perhaps similar RH's Visual Explain, for example). This would solve the general problem: "the user didn't write the query they intended to write", rather than a very narrow subset ("the user forgot a join clause and accidentally computed a cartesian product").
-Neil
---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
