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
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
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
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
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
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
