Nested Sets + PostgreSQL TRIGGER

Это сколько времени надо было потратить… Огромное спасибо

Благодарен за столь подробные примеры. Ждем кода для MySQL.

Сколько времени ушло на поиск решения?

и как быстро это работает? не лучше ли чуток модернизированным «материализованным путём» пользоваться.

_{Disclaimer: читал малец по диагонали}
Сумбурно как-то. Вы бы привели примеры запросов, которые такая схема делает быстрыми и удобными, а то я что-то не понял. Как эта схема помогает, например, решать типичные для древовидной структуры задачи типа «найти всех потомков данного узла» или «найти всех родителей данного узла». Или вы там что-то быстро выбираете по ключам (left_key/right_key)? В таком случае, получается — заново изобретаем индексы?
Кстати о рекурсии — в недавно вышедшей 8.4 появились рекурсивные запросы — не интересовались?
Комментарии по коду (не имеющие, впрочем, отношения к существу вопроса):

CREATE OR REPLACE FUNCTION lock_ns_tree(integer)
    RETURNS boolean AS
$BODY$
DECLARE tree_id ALIAS FOR $1;
    _id INTEGER;
BEGIN
    SELECT id
        INTO _id
        FROM ns_tree
        WHERE tree = tree_id FOR UPDATE;
    RETURN TRUE;
END;
$BODY$
  LANGUAGE 'plpgsql' VOLATILE
  COST 100;

1. Алиас для параметра — как-то архаично и неудобно, лучше писать сразу lock_ns_tree(tree_id integer).
2. Используйте PERFORM (PERFORM id FROM ns_tree ...), дабы не плодить ненужных переменных.
3. Функция — типичный кандидат на STABLE, VOLATILE не стоит ставить из соображений производительности.

Много лет назад элегантно решил эту задачу следующим способом:

Есть основная «обычная» таблица foo(id, parent_id, label); на которой висит куча триггеров, которые уже «ведут» второстепенную таблицу foo_traversed(id, lft, rgt, level); таким образом никаких проблем с лочкой или непониманием со стороны нет. Запросы стандартных задачь делам либо через функции либо через LEFT JOIN