3 ms·
The ltree[1] extension that is shipped with PostgreSQL does that pretty well. [1] https://www.postgresql.org/docs/current/static/ltree.html https://www.postgre
by jlg23 11y ago
The ltree[1] extension that is shipped with PostgreSQL does that pretty well.
[1] https://www.postgresql.org/docs/current/static/ltree.html https://www.postgresql.org/docs/current/static/ltree.html
- radiowave 11y agoRight, and there's a huge number of index-assisted ways in which in can be queried, but ltree has some restrictions on what nodes can be called, which can be a problem if you're trying to represent hierarchies of nodes that already exist. Most of the operations described in the article are performed by using the && (overlaps) operator, which can make use of a GIN index (though the article doesn't mention this), so probably the article's approach will work OK.
- netghost 11y agoOne other factor, I think ltree is based around strung keys, while the approach we took used integers representing priority ordering . So an integer array worked quite nicely. Ltree seems like it would be good for representing a named categorical hierarchy. I'd love to see how ltree performs though.
- cabirum 11y agoIs it still supported and tested? The last entry of the extension's homepage is from 2006 [1], I assume this is when the original authors stopped it's development. [1]: http://www.sai.msu.su/~megera/postgres/gist/ http://www.sai.msu.su/~megera/postgres/gist/
- radiowave 11y agoIt's supplied as standard with Postgres. If they weren't willing to accept a bug report against it, they wouldn't be shipping it. What testing it receives I don't know, but I'm quite prepared to suppose that nobody's found a bug in it since 2006.