pg.ddx.io  pgsql-sql@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Robert Treat <xzilla@users.sourceforge.net>
To: pgsql@ac6rm.net
Cc: pgsql-sql@postgresql.org
Subject: Re: celko nested set functions -- tree move
Date: 26 Nov 2002 11:00:40 -0500
Message-ID: <1038326440.17254.20.camel@camel> (raw)
In-Reply-To: <63745.24.52.245.104.1038287584.squirrel@webmail.ac6rm.net>
References: <63745.24.52.245.104.1038287584.squirrel@webmail.ac6rm.net>

I think you should take a closer look at Greg's function. It is uses
lfts as parameters in the function mainly just to make the function
implementation independent; I was able to easily adapt it to my schema
which uses unique id's for each object in the tree hierarchy.

After looking your function over, I also have some concerns about moving
children to new parents with lft and rgt smaller than the child, because
the math is different depending on which way your moving in the tree.
It's possible that your use of treeid's and universe id's makes up for
this, though it's a little hard to discern without seeing the schema,
perhaps you can post schema and some test data? 

I'm also curious how many nodes you have in your tree, and at how many
levels. It seems like your function would have performance issues over
large trees since it requires 3 select statements, 3 updates, and a lock
table. Compare this with Greg's function which requires 2 selects and 1
update, with no lock. 

As a final note, you might want to rewrite your select statements like:
SELECT 
	rgt, universeid, treeid  
FROM 
	list_objects
WHERE 
	objid_auto=t_newparent
INTO 
	newparentrgt, newparentuid, newparenttid;

I think it's more readable and probably a little more efficient since
you are doing less variable assignment.

Robert Treat

On Tue, 2002-11-26 at 00:13, Martin Crundall wrote:
> I'm not sure that keying off lft is safe in a multi-user environment.  I
> opted to create and use an objid on the tree definition table, since its
> identity is static.  I also found that when trees get active, allowing for
> tree IDs increased operation speed quite a bit (i actually push this to
> two levels--a 'universe id' and then a 'tree id').  Here's my version. 
> Clearly not as elegantly written, but nothing's gone awry yet.
> 
> --
> ---------------------------------------------------------------------------
> --    Title: trackmyproject_tree_move()
> -- Function: moves a tree branch in the hierarchy from one parent to
> --           another.
> --    parms: srcobj       the branch/object to be moved
> --           newparent    the new parent for the object to be moved
> --  Returns: zero
> --
> ---------------------------------------------------------------------------





view thread (3+ messages)  latest in thread

Message-ID: <1038326440.17254.20.camel@camel>
Permalink:  ../1038326440.17254.20.camel@camel/
Also on:    postgresql.org/message-id/1038326440.17254.20.camel@camel

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-sql@postgresql.org
  Cc: xzilla@users.sourceforge.net, pgsql@ac6rm.net
  Subject: Re: celko nested set functions -- tree move
  In-Reply-To: <1038326440.17254.20.camel@camel>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox