I'm just getting started with PostgreSQL, and I love it; I hope to
eventually use it in all of my projects. The only thing holding me back is
the lack of a good way to perform left outer joins. I scanned all of the
mailing lists, and it seems that the issue has come up several times, and
people have shown interest, but there has been no visible progress.
In my experience, when I code a one-sided join I'm generally thinking "for
selected objects from this class, fetch attributes plus related data from
other classes". Based on my vague impression that PostgreSQL converts some
queries internally into nested loops, I suggest the following new statement
(partially stolen from InterBase's stored procedure language):
FOR ... [WHERE ...] [GROUP BY ...] [HAVING ...] DO <statement>
This would convert directly into a nested loop around the <statement>, and
would replace any empty SELECT result within <statement> with a single row
in which "local" object attributes are NULL. The current object(s) from the
FOR ... DO would be accessible inside <statement>. Then one could write the
SQL92:
SELECT p.name, c.name FROM parents p LEFT JOIN children c ON c.parent = p.id
as
FOR parents p DO SELECT p.name, c.name FROM children c WHERE c.parent = p.id
More complex constructions could involve nested FOR ... DO's, in which case
the inner FOR ... DO's would each invoke their <statement> at least once,
with NULL objects if necessary. A list of all widgets, exploded into parts
and sub-parts if possible, could be written:
FOR widgets w DO FOR parts p1, widgets wp1 WHERE p1.widget = w.id and p1.part = wp1.id DO SELECT w.name, wp1.name,
wp2.nameFROM parts p2, widgets wp2 WHERE p2.widget = p1.part and p2.part = wp2.id
Does this look more or less complicated to implement and use than the SQL92
LEFT JOIN? Is it too non-standard to live? Too ambiguous or narrow? I'd
implement it myself, but I'm light-years away from being able to contribute
anything but bug reports and ideas right now.
Thanks,
Evan Simpson
