Re: Is postorder tree traversal possible with recursive CTE's?
От | Asif Ali |
---|---|
Тема | Re: Is postorder tree traversal possible with recursive CTE's? |
Дата | |
Msg-id | DM5PR2001MB1083C2D94EF3B5A6D1BB74728B700@DM5PR2001MB1083.namprd20.prod.outlook.com обсуждение исходный текст |
Ответ на | Re: Is postorder tree traversal possible with recursive CTE's? (Paul Jungwirth <pj@illuminatedcomputing.com>) |
Список | pgsql-general |
how the fuck i unsubscribe to this mailing list , i get more than 100 emails a day
Bye
From: Paul Jungwirth <pj@illuminatedcomputing.com>
Sent: Wednesday, June 20, 2018 2:31 AM
To: pgsql-general@lists.postgresql.org
Subject: Re: Is postorder tree traversal possible with recursive CTE's?
Sent: Wednesday, June 20, 2018 2:31 AM
To: pgsql-general@lists.postgresql.org
Subject: Re: Is postorder tree traversal possible with recursive CTE's?
On 06/19/2018 02:05 PM, Alban Hertroys wrote:
> On the more theoretical front: The question remains whether it is possible to calculate fields in post-order tree traversal. I think that would be a semantically proper way to express this type of problem and it wouldn't need the kinds of pre/post-processing that after-the-fact aggregation (like in above solution) requires. So, leaner, and probably faster.
> That implies that the SQL committee thought of the possibility in the first place though, which I'm beginning to doubt...
If this interests you, you might enjoy this StackOverflow question:
https://stackoverflow.com/questions/35956486/generate-nested-json-with-couting-in-postgresql
Briefly, how do you construct a nested JSON structure from a recursive
CTE? The only answers at that link rely on plpgsql, but of course that
is cheating. :-) I took a stab at it a couple years ago but couldn't
figure it out, and it seemed like post-order processing was exactly the
missing piece.
If anyone has any ideas I'd be intrigued to hear them!
--
Paul ~{:-)
pj@illuminatedcomputing.com
> On the more theoretical front: The question remains whether it is possible to calculate fields in post-order tree traversal. I think that would be a semantically proper way to express this type of problem and it wouldn't need the kinds of pre/post-processing that after-the-fact aggregation (like in above solution) requires. So, leaner, and probably faster.
> That implies that the SQL committee thought of the possibility in the first place though, which I'm beginning to doubt...
If this interests you, you might enjoy this StackOverflow question:
https://stackoverflow.com/questions/35956486/generate-nested-json-with-couting-in-postgresql
Briefly, how do you construct a nested JSON structure from a recursive
CTE? The only answers at that link rely on plpgsql, but of course that
is cheating. :-) I took a stab at it a couple years ago but couldn't
figure it out, and it seemed like post-order processing was exactly the
missing piece.
If anyone has any ideas I'd be intrigued to hear them!
--
Paul ~{:-)
pj@illuminatedcomputing.com
В списке pgsql-general по дате отправления: