[SQL] Nested Sets

2005-04-16 Thread A. Kulikov
Hi all, I have just moved to PostgreSQL from MySQL and am willing to employ all the capabilities PostgreSQL has to offer. In MySQL I have had implemented Joe Celko's Nested Sets quite a while ago, extending them with some additional fields to cache data such as the level of the node and a referenc

Re: [SQL] Nested Sets

2005-04-16 Thread Troels Arvin
On Sat, 16 Apr 2005 16:31:43 +0400, A. Kulikov wrote: > Has anyone implemented a pretty Nested Sets solution in > PostgreSQL? Maybe this is useful? : http://threebit.net/tutorials/nestedset/tutorial1.html -- Greetings from Troels Arvin, Copenhagen, Denmark ---(end of

Re: [SQL] Nested Sets

2005-04-16 Thread A. Kulikov
Seen this before. The solution is rather lame, as most of the logic is shifted out to the code, whereas it could have been implemented in the database directly. I have managed to get a move_tree algorythm working rather fast and glitch free by now, yet I am wondering if there are other directions t

Re: [SQL] Nested Sets

2005-04-16 Thread Andrew Sullivan
On Sat, Apr 16, 2005 at 06:28:27PM +0400, A. Kulikov wrote: > btw, do stored procedures (user functions in other words) have to > implement table locking or be carried out inside a transaction such > that the nested set indexes remain intact? They're always in a transaction. Everything in Postgre

Re: [SQL] Nested Sets

2005-04-16 Thread Troels Arvin
On Sat, 16 Apr 2005 14:14:57 -0400, Andrew Sullivan wrote: > You shouldn't need to do anything special around table > locking. - Except of one wants "True Serializability" (see chapter 12.2 in the manual). But I don't know if it's possible to handle table locking from within a user defined functio

Re: [SQL] Nested Sets

2005-04-16 Thread Christopher Browne
After takin a swig o' Arrakan spice grog, [EMAIL PROTECTED] (Troels Arvin) belched out: > On Sat, 16 Apr 2005 14:14:57 -0400, Andrew Sullivan wrote: >> You shouldn't need to do anything special around table >> locking. > > - Except of one wants "True Serializability" (see chapter 12.2 in the > man