From: | talk to ben <blo(dot)talkto(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #17061: Impossible to query the fields of the tuple created by SEARCH BREADTH FIRST BY .. SET .. |
Date: | 2021-08-11 13:41:25 |
Message-ID: | CAPE8EZ5KGW5K_dqnvo_pJeNxwbM_L4wH+iahc1iX2L=AmT88oQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Sat, Jul 31, 2021 at 3:40 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> On Tue, Jul 06, 2021 at 07:56:10PM +0200, Peter Eisentraut wrote:
> > It's not really meant to be used that way. I'm not sure whether it's
> worth
> > spending extra effort on.
>
> Peter has contacted the RTM about this issue, and we are classifying
> this item as a "won't fix" per this argument.
> --
> Michael
>
Hi,
Sorry, for the delayed answer.
I am a little surprised, when I see client who create that kind of
hierarchical queries they usually
want to have the depth or the path in the return query. And then they
realise that they should
protect them selves from loops and deep recursions after an incident where
queries wouldn't
stop or ran for too long.
So if they want the data and the protection in v14, they have to either :
* use the feature but recompute the column that the feature built
internally (or use the json trick);
* not use the feature at all and do it the old way.
It seems counterintruitive to me.
Thanks for the explanation and the awesome work on PostgreSQL.
Benoit
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2021-08-11 13:50:16 | Re: BUG #17140: pg_try_advisory_xact_lock produces a WARNINIG on unsuccessful lock |
Previous Message | hubert depesz lubaczewski | 2021-08-11 08:35:40 | Re: I/O timigns don't include time for temp buffers |