Le jeudi 25 janvier 2007 à 12:12 -0500, Gregory Stark a écrit :

> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > > That's basically how the existing patch approached the problem. It 
> > > invents a
> > > new type of join and a new type of tuplestore that behaves this way. This 
> > > has
> > > the advantage of working the way Oracle users expect and being relatively
> > > simple conceptually. It has the disadvantage of locking us into what's
> > > basically a nested loop join and not reusing existing join code so it's 
> > > quite
> > > a large patch.
> > 
> > I believe our Syntax should be whatever the standard dictates,
> > regardless of Oracle.
> Well the issue here isn't one of syntax. The syntax is really an orthogonal
> issue. The basic question is whether to treat this as a new type of plan node
> with its behaviour hard coded or whether to try to reuse existing join types
> executing them recursively on their output. I can see advantages either way.
> As far as the syntax goes, now that I've actually read up on both, I have to
> say: I'm not entirely sure I'm happy IBM won this battle. The Oracle syntax is
> simple easy to use. The IBM/ANSI syntax is, well, baroque. There's a certain
> logical beauty to it but I can't see users being happy trying to figure out
> how to use it.

I agree with THAT, it's clear that WITH RECURSIVE is more standard...
but for the SQL developper CONNECT BY is a paradise... the syntax is
clear and powerful... That's why we've chosen to developp our queries
with that (using the connectby() function and the evgen potemkin.'s
patch (http://gppl.moonbone.ru/)

Ce message et les �ventuels documents joints peuvent contenir des informations 
Au cas o� il ne vous serait pas destin�, nous vous remercions de bien vouloir 
le supprimer et en aviser imm�diatement l'exp�diteur. Toute utilisation de ce 
message non conforme � sa destination, toute diffusion ou publication, totale 
ou partielle et quel qu'en soit le moyen est formellement interdite.
Les communications sur internet n'�tant pas s�curis�es, l'int�grit� de ce 
message n'est pas assur�e et la soci�t� �mettrice ne peut �tre tenue pour 
responsable de son contenu.

Reply via email to