On Jul 10, 2009, at 12:06 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> I took a look at this and it seems that #3 can be implemented with
>> essentially no additional code (the handful of lines I added where
>> more than balanced out by some simplifications in ruleutils.c). Of
>> course you still don't have to like it. :-)
>
> You're right, I don't. Even if I thought this were a good idea, which
> I most definitely do not, the need to add a nonstandard fully-reserved
> word is sufficient reason to reject it. (The patch tries to pretend
> it's not going to reserve the word, but that only works because you
> have
> carefully changed only one of the five JOIN productions, leading to
> bizarrely non-orthogonal syntax.)
Well, it's pretty obvious that only one of those productions is
actually a problem, and that is the one which produces an undecorated
JOIN. The others could all be changed easily enough, but they add no
expressive power, so I didn't think it very worthwhile to add MORE non-
standard syntax. In any event, the current non-orthogonality is
exponentially more bizarre: you can constrain the join order by
setting join_collapse_limit to 1, but then you must write the joins
you want constrained using JOIN and the others as FROM items, which of
course doesn't work at all for LEFT or RIGHT joins and will have
random and unpredictable effects on subqueries pulled in via VIEWs.
Needing to write INNER to be able to use FORCE pales by comparison.
That having been said, I'm not excited about pushing water up a hill.
The important thing here is to remove the collapse limits; providing a
tool to control the join order that won't make you want to beat your
head in a brick is just something that can be trivially done with no
extra code, not my primary goal.
...Robert