[Fwd: SQL3 recursive unions]

From: Ron Peterson <rpeterson(at)yellowbank(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: [Fwd: SQL3 recursive unions]
Date: 2000-06-15 19:58:40
Message-ID: 39493570.6BC46A4C@yellowbank.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)yellowbank(dot)com

Responses

Browse pgsql-general by date

  From Date Subject
Next Message W. van den Akker 2000-06-15 20:22:52 Error-message in other language
Previous Message Andrew Sullivan 2000-06-15 18:38:27 Re: Lock record