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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>
Cc: blo(dot)talkto(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Subject: Re: BUG #17061: Impossible to query the fields of the tuple created by SEARCH BREADTH FIRST BY .. SET ..
Date: 2021-09-19 14:20:26
Message-ID: 1550447.1632061226@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec> writes:
> Just to add fuel to the fire, I just noted that you cannot create a view
> based on a recursive CTE using this syntax.
> ...
> ERROR: column "breadth" has pseudo-type record

Yeah, I've run into that too. There's no time to reconsider the
implementation for v14, but I'd sure like to see this revisited
later. I'm kind of wondering if, instead of a single RECORD
column, we could add each of the SEARCH columns and the depth
column as a separate resjunk column. (However, I'm not sure
how to extend that approach to the DEPTH FIRST case, which
wants an array.)

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2021-09-19 15:04:10 Re: BUG #17194: Issue with pgoutput
Previous Message PG Bug reporting form 2021-09-19 09:17:08 BUG #17195: Can't bind $1::int param when I use COPY TO STDOUT statement - libpq, C++