Basically, what you have is something called an adjacency list.
I have this table:
Code:
select *
from prods;
And to get the path, you need this query (fix accordingly):
Code:
select p1.*, p2.*
from prods p1
left join prods p2
on p1.pid = p2.fid;
Which outputs this:
If you have to go five levels deep, you can see where that is going....
Code:
select p1.*, p2.*, p3.*
from prods p1
left join prods p2
on p1.pid = p2.fid
left join prods p3
on p2.pid = p3.fid
-- etc etc etc
;
Since you already have path enumeration with something like this:
Code:
create table paths (path text primary key);
insert into paths (path)
values ('1, 2, 3, 4');
You'll have to split the path with a "like" query, split the string on ",", spin through all of those numbers, coerce to int, etc (adjust this to arrays if you are using it).
Basically, it would be a crazy query even if you have recursive CTEs available. If you don't have recursive CTE's, you'd have to split the string into a subselect, then self-join on the table 5 times the same as shown above. This will be an eye-glazer, which I think nullifies the point of using the extra table.
In effect, the first query, although rather lame, would be much easier to do than combining path enumeration, but all if this is much much easier (and more efficient) to do with a procedure.
I did some searches on adjacency lists and path enumerations, but didn't find a lot of good information on them. They are accurate, but pretty scattered, but those are the official terms you want to look for.