Re: BUG #17061: Impossible to query the fields of the tuple created by SEARCH BREADTH FIRST BY .. SET ..

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

In response to

Browse pgsql-bugs by date

  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