On 2017-07-25 01:15:56 +1200, Tim Uckun wrote:
> I don't like the approach with a large increment. It would mean complicated
> logic to see if you filled the gap and then update all the other peers if you
> did. It sounds like the re-order is going to be expensive no matter what. My
> primary conce
I don't like the approach with a large increment. It would mean complicated
logic to see if you filled the gap and then update all the other peers if
you did. It sounds like the re-order is going to be expensive no matter
what. My primary concern are race conditions though. What if two or more
user
> On 24 Jul 2017, at 9:02, Tim Uckun wrote:
>
> I have read many articles about dealing with hierarchies in postgres
> including nested sets, ltree, materialized paths, using arrays as parentage,
> CTEs etc but nobody talks about the following scenario.
>
> Say I have a hierarchy like this
>
On 24/07/2017 10:02, Tim Uckun wrote:
I have read many articles about dealing with hierarchies in postgres including
nested sets, ltree, materialized paths, using arrays as parentage, CTEs etc
but nobody talks about the following scenario.
Say I have a hierarchy like this
1
1.1
1.1.1
1.1.2
1
I have read many articles about dealing with hierarchies in postgres
including nested sets, ltree, materialized paths, using arrays as
parentage, CTEs etc but nobody talks about the following scenario.
Say I have a hierarchy like this
1
1.1
1.1.1
1.1.2
1.2
1.3
2
2.1
In this hierarchy the order
