On Jul 10, 2009, at 12:06 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
Robert Haas <robertmh...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
