[Fwd: SQL3 recursive unions] - Mailing list pgsql-general

From Ron Peterson
Subject [Fwd: SQL3 recursive unions]
Date
Msg-id 39493570.6BC46A4C@yellowbank.com
Whole thread Raw
Responses Re: [Fwd: SQL3 recursive unions]  (Michael Meskes <meskes@postgresql.org>)
List pgsql-general
PostgreSQL's TODO list (http://www.postgresql.org/docs/todo.html) makes
reference to implementing SQL3 recursive queries.  Where does this task
fall in the overall priority of things?  I hate to just whine without
offering to help, but I think this would be a rather big bite to chew.
(Actually, I would be happy to help, if anyone had any suggestions about
what I might be able to do)

The attached message includes an example of recursive SQL syntax from
IBM's DB2.

I keep thinking that must be some way to do something similar using
PostgreSQL in it's current state, but if so, elegant solutions elude
me.  Drives me nuts.

I want to do an exploded parts list.  I want to create a tape archive
database that stores directory entries efficiently.  Threaded
discussions.  Business hierarchies.  Etc.  Sometimes, fixed depth
hierarchies just don't cut it.

I thought, once, that DB master Joe Celko had described an elegant
solution using standard SQL (http://www.dbmsmag.com/9603d06.html).  But
you don't have to think too hard before you realize that using this
method, insertions and deletions could easily require updates to every
row in your table.

Oracle's CONNECT BY, LEVELS, & START AT are nice.  But I've heard said
they don't provide the same degree of flexibility that recursive queries
do, although Oracle's methodology may be faster...??

Am I alone in the universe?  If I can't get the feature I want, I guess
I'll settle for some sympathy...

Woe is me.

________________________
Ron Peterson
rpeterson@yellowbank.comHave you looked at the recursive union syntax in SQL3? It seems DB2 is
the only database that support it right now, but it's an interesting
syntax that allows for all kinds of explosions.

Here's an example from DB2's documentation, cleaned up a bit:

with rpl (part, subpart, quantity) as
(
  select root.part, root.subpart, root.quantity
    from partlist root
    where root.part = '01'
  union all
    select child.part, child.subpart, child.quantity
      from rpl parent, partlist child
      where parent.subpart = child.part
)
select distinct part, subpart, quantity
  from rpl
  order by part, subpart, quantity

If this looks confusing -- it's not so intuitive, and introduces two new terms, the temporary-table "with" syntax and
"unionall" -- the documentation explains this query thus: 

<quote>
The above query includes a common table expression, identified by the name RPL, that expresses the recursive part of
thisquery. It illustrates the basic elements of a recursive common table expression.  

The first operand (fullselect) of the UNION, referred to as the initialization fullselect, gets the direct children of
part'01'. The FROM clause of this fullselect refers to the source table and will never refer to itself (RPL in this
case).The result of this first fullselect goes into the common table expression RPL (Recursive PARTLIST). As in this
example,the UNION must always be a UNION ALL.  

The second operand (fullselect) of the UNION uses RPL to compute subparts of subparts by having the FROM clause refer
tothe common table expression RPL and the source table with a join of a part from the source table (child) to a subpart
ofthe current result contained in RPL (parent). The result goes back to RPL again. The second operand of UNION is then
usedrepeatedly until no more children exist.  

The SELECT DISTINCT in the main fullselect of this query ensures the same part/subpart is not listed more than once.
</quote>

--A.

"Jon Udell" <udell@monad.net> wrote in message news:393531
01.C8FC995@monad.net...
> > I'm not talking about complicated, unusual, or atypical data
structures here.
> > I'm talking about A GODDAMN TREE.  Why can't SQL do this!!!
> >
> > As others have pointed out - IT CAN!  It's been talked about for
years!
> > It's just not a standard part of a typical SQL implementation.
> > And I'm just saying it should be.
>
> What would the syntax look like, in your view? Things mentioned in
this
> thread have included the technique described in Celko Chap 26
(standard,
> but ungainly) and Oracle's CONNECT BY (nonstandard, but concise).
>
> What kind of tree operations would you like to be able to express in
> SQL, and how would you like to express them?
>
> --
> Jon Udell | <http://udell.roninhouse.com/> | 603-355-8980



pgsql-general by date:

Previous
From: Andrew Sullivan
Date:
Subject: Re: Lock record
Next
From: "W. van den Akker"
Date:
Subject: Error-message in other language