Я себе позволил поправить немного английский в readme.html.

This is a patch which allows PgSQL perform hierarchical queries like Oracle does.

The patch itself is distributed under GPL. No warranty of any kind is given, use it at your option.

Lets the tree looks like the following:

...weakness of such approach is that, we can't sort leaves in some
custom order.

Если это полезно на твой взгляд, используй.

Классная и очень удобная штука!

Черт! Если бы я знал раньше, то не делал бы рекурсивные запросы для чтения деревьев... У меня как раз все хранится в такой форме как и нужно.

Жень, молодец! Оченно хорошую вешь делаешь! Всяческих тебе респектов!

Да gppl. Человек правильно говорит на счет английского. Надо еще будет на странице index.eng.html английский поправить.

Borka.

на счет рекурсивных запросов в деревьях это ты зря есть алгоритм специальный для деревьев под SQL, все рулез и никакой рекурсии

Я не закончил, думал запощу, а то можен нах. ни кому не нужно. Там еще много.

Всех респектов автору! Есть надежда, что эта функциональность появится в офф. версии и не надо будет накладывать патч?

В догонку, пацаны, может кто знает - наткнулся на грабли у постгреса с курсорами: при объединении нескольких таблиц, курсор фетчится вперед, доходит до конца, а в обратную сторону никак. Приходится заливать данные во временную таблицу и по не курсорить. Кто сталкивался?

В целях ликбеза

Приведите пожалуйста пример реальных данных, для которых такое представление необходимо.

С уважением Евгений

2Banshee: фенкс, правильный английский был бы очень полезен, что здесь есть я вставлю, остальное если хочешь вышли на мыло. 2Korwin: в офф. версии этот патч если появится, то не скоро. они делают упор (по крайней мере говорят, пока ничего не сделано) на рекурсивные запросы SQL99 (как в DB2) которые мощнее, но менее удобны для postprocess. 2Dimez:ты тот Dimez который я думаю? рад тебя слышать:)

Да я б с удовольствием... :) Но тут трудно развернуться.
Просто занимаюсь разработкой "финансовой" системы, ну и там есть 
склад, состоящий из 5 справочников + журнал транзакций по складу,
все это связано с журналом бух. проводок, который в свою очередь
связан с журналом операций... и т.д. Так вот, если курсорить уже по 3-м
таблицам, начинаются проблемы. До этого решал их с помощью добавлением
ORDER BY ... ( кажется при этом постгрес строит временную таблицу).
А тут мне курсорить приходится аж по 8-ми таблицам, т.к. приходится
учитывать остатки, время проведения операций, ну и сам склад. Вот 
такие, блин, бухштучки .

Спасибо за внимание.

2Евгений - "Приведите пожалуйста пример реальных данных, для которых такое представление необходимо." В моем случае это каталогизатор по разделам. Надо показывать кол-во вхождений записей в каждый подраздел с симмированием всех записей в его дочерних разделах. И тут либо сам пишешь рекурсивные запросы, либо получаешь за один раз выборку.

Добрый день

Это действительно необходимо, если уровень вложенности разделов не ограничен, но на сколько я понимаю всегда можно обойтись фиксированным числом уровней, тогда достаточно одной таблицы - и требуемый запрос тоже отрабатывается в одно действие - или я что-то не понимаю.

Где нибудь есть что почитать по представлениям данных в БД?

С уважением Евгений

> Это действительно необходимо, если уровень вложенности разделов не 
> ограничен
В моем случае так и есть, поскольку это только движок, а наполнение и структура заранее не определена и может быть любой сложности/вложенности.


> но на сколько я понимаю всегда можно обойтись фиксированным
> числом уровней, 
С фикс. числом уровней начинаются проблемы когда в будущем это
ограничение мешает и надо его убирать и вот на этом этапе появляются 
проблемы. И сложность их решения зависит от изначальной продуманости 
кода и организации таблиц. В общем похоже на танец с бубнами.

> тогда достаточно одной таблицы - и требуемый запрос 
> тоже отрабатывается в одно действие - или я что-то не понимаю.
И как это вы себе представляете? Допустим имеется структура:
r_000:
  + c_001
  + c_002
    + c_021
    + c_022
      + c_121
  + c_003

Какая должна быть таблица и запрос который отрабатывает в одно 
действие чтобы получить следующую последовательность данных:
c_002
c_021
c_022
c_121

Для этого можно завести доп. столбец типа sort_index и по нему делать 
типа:
sort_index >= c_002_sort_index AND sort_index <= c_121_sort_index
Но тогда будут сложности при вставке, удалении и переносе разделов 
между родителями.

Да, я знаю алгоритм дерева, где можно избежать рекурсии из-за ограниченности степени вложенности. Но в моём конкретном случае он не подходит. У меня есть как бы виртуальная файловая система где можно создавать каталоги и подкаталоги хоть до посинения. Правда всё несколько сложнее и за один проход должны считыватся ещё и права каталогов в зависимости от текущего пользователя, но по ходу при помощи иерархического запроса я смог бы обойтись без рекурсии.

2dem1urg. Знаешь, у нас достаточно похожи задачи, только у меня разделы у тебя каталоги. И у тебя и у меня необходимо проверять права на доступ. Как ты решил это. Путем SQL либо уже кодированием в языковыми командами?

Кстати, вместо sort_index можно просто использовать level как степень вложенности. Тогда особых проблем нет, но просто в запросе будет фигурировать одна тааблица 2 раза связанная сама с собой.

Как я решил... Я не понимаю что значит "кодированием..." поэтому наверное я решил это путём SQL. На самом деле у меня наверное не совсем то, что у тебя. Дело в том, что у меня есть группы прав и каждый пользователь может входить в несколько групп. У каждой папки устанавливаются права для группы. Вся лажа в том, что если у пользователя нет прав чтобы даже видеть папку (у меня это возможно), то соответственно у него не должно быть и прав к папкам внутри неё. Поэтому теоретически чтобы узнать права папки, то для этого нужно проверить права всех папок которые находятся на пути к корню дерева. Если ещё учесть, что для каждой папки нужно найти максимальные права из всех групп принадлежащих данному пользователю, то получается совсем плохо и медленно. Поэтому у меня есть вспомогательная тааблица, где хранятся права в виде: folder_id, user_id, right. Эта тааблица обновляется при любой измене прав (не вся конечно, а только то, что нужно). Ну а потом я рекурсивно считываю все папки с их правами. Если у тебя нет групп и невидимых папок, то проблем вообще нет.

Спасибо за ответ. Да групп у меня нет, но есть невидимые папки. Я сознательно упростил работу с правами чтобы было меньше мороки (хотя сейчас уже хотелось бы и поболее ограничивать/настраивать).

Проверку прав на видимость/чтение папки можно реализовать на PL/pgSQL.