PROPOSAL: Statement for one-sided joins
От | Evan Simpson |
---|---|
Тема | PROPOSAL: Statement for one-sided joins |
Дата | |
Msg-id | 008d01bee354$91a76fa0$8d84b2d8@token.hapenney.com обсуждение исходный текст |
Список | pgsql-sql |
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
В списке pgsql-sql по дате отправления: