From: | Kev <kevinjamesfield(at)gmail(dot)com> |
---|---|
To: | pgsql-patches(at)postgresql(dot)org |
Subject: | Re: WITH RECURSIVE patch V0.1 |
Date: | 2008-05-20 14:03:16 |
Message-ID: | cb2adde0-0724-474b-9810-cf0ffdae8eb6@26g2000hsk.googlegroups.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
On May 19, 1:17 am, da(dot)(dot)(dot)(at)fetter(dot)org (David Fetter) wrote:
> On Mon, May 19, 2008 at 12:21:20AM -0400, Gregory Stark wrote:
> > It's quite possible to have clauses which will limit the output but
> > not in a way the database can determine. Consider for example a
> > tree-traversal for a binary tree stored in a recursive table
> > reference. The DBA might know that the data contains no loops but
> > the database doesn't.
>
> I seem to recall Oracle's implementation can do this traversal on
> write operations, but maybe that's just their marketing.
That's how I implement (id, name, parent)-trees as a DBA, having an
insert/update trigger function check_no_loops(), but I'm not sure that
it would be faster than the hash method suggested by Hannu Krosing. I
guess it depends on whether you're inserting/updating or selecting
more. Does it make sense to leave the option to the user, whether to
check for infinite recursion just in time or not?
Kev
From | Date | Subject | |
---|---|---|---|
Next Message | Florian G. Pflug | 2008-05-20 14:24:32 | Re: triggers on prepare, commit, rollback... ? |
Previous Message | Hannu Krosing | 2008-05-20 11:50:58 | Re: triggers on prepare, commit, rollback... ? |
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2008-05-20 14:12:42 | Re: Patch for psql 8.0, 8.1 and 8.2 backwards compatibility |
Previous Message | Bryce Nesbitt | 2008-05-20 05:49:14 | Patch for psql 8.0, 8.1 and 8.2 backwards compatibility |