Jacob, > cons: > - its not standard SQL (uses oracle style syntax)
Which is, plain and simple, a deal-breaker. You can count on me to vote against inclusion of any patch which uses non-standard SQL when a standard syntax is available. Further, the IS_CONNECTED_BY() function is available in /contrib/tablefunc. I fail to see why the Evgen patch is even necessary. More Cons: -- The patch has shown some significant performance issues according to the reports of several people on the performance list who have used it. This is likely due to insufficient understanding of planner estimates. -- The patch has several serious bugs. One of them, apparently by report on pgsql-sql, is truncation of strings at the 8K page limit (in other words, a lack of integration with TOAST). > - it would add a feature that many people miss already for ages. all > existing workarounds are a pain in the ass, and are too slow for realistic > applications. Huh. I've written 4-5 applications which required recursive queries in the last 3 years. All of them worked with PL/pgSQL or C recursive functions; performance was even pretty good. - full SQL99 compliant recursive queries are much more > complex, i.e. i think it is even unlikely that they will find their way > into 7.6. Currently, nobody is working on SQL99/2003 recursive queries. So, you are correct, there is no timeline for inclusion. You could fix this. Get hacking, or hire a hacker. > - Evgen DID publish this patch under GPL, see: We are a BSD project. So we cannot include any GPL patches, even if we wanted to. > - the code doesnt look too bad (although im not the right person to judge > such things), and it seems the developer takes care of bugfixes (and > possibly also feature requests like sql99 compliance?), i.e. this might be > a realistic startingpoint for SQL99 compliant recursive queries. But it's not. Oracle's "IS CONNECTED BY" syntax is very different from the SQL99 syntax, and some of the math is different. If anything, implementing the Evgen patch would complicate implementation of the SQL99 syntax. > i am aware of the fact that tom lane pointed to the fact that Andrew > Overholt did work towards SQL99 compliant recursive queries. it would be > interesting to know andrews opinion how much more work would be needed to > get a SQL99 compliant version out based on the work he has done so far This is the line you should pursue, rather than trying to get people to accept Evgen's patch. -- Josh Berkus Aglio Database Solutions San Francisco ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match