Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m0pJY-0002eT-Iv for pgsql-bugs@arkaria.postgresql.org; Tue, 06 Jul 2021 17:56:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1m0pJ1-0007yQ-VZ for pgsql-bugs@arkaria.postgresql.org; Tue, 06 Jul 2021 17:56:23 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m0pJ1-0007vW-OT for pgsql-bugs@lists.postgresql.org; Tue, 06 Jul 2021 17:56:23 +0000 Received: from wforward3-smtp.messagingengine.com ([64.147.123.22]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m0pIu-0002LE-Oo for pgsql-bugs@lists.postgresql.org; Tue, 06 Jul 2021 17:56:22 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailforward.west.internal (Postfix) with ESMTP id A1F501AC1B8B; Tue, 6 Jul 2021 13:56:14 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Tue, 06 Jul 2021 13:56:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=8wP1Cm3xTmZmdHOeWu/+FsEV/yWS4XuhojlA1Nkci OQ=; b=vKI8wlrOEtLtN2AmAmIkZiBVzkics9kEp+MnsXhkNVS+OsXXdM+Nd2tJg srDlCBHBtcTS3TkZ9NrlMMwYGkayKO5o7+iM9kKNePlnG9ZBZN5f69wciq0Oh5mD 0JxLz3kLxoKneXyz1PGBoD44EsAf/Qf4yh+3SWZRg/H6VRItfxgcou72f9Huq6hm T/Rg/5ClGiJSZftZIhDt52gSPw8mome1ViPkQSggr59vBNJcCeGdTCekkKaU8RS1 qp9wcQ7kF5fTUZaG3tfH0GvcwGwzDtb7PDuly3DWhqHxbTudXEsbOxosoRkBhsnl yG+MclPSZLeEkKUlatZOs3ZLeI2qw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrtddtgdejiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtgfesthejre dttdefjeenucfhrhhomheprfgvthgvrhcugfhishgvnhhtrhgruhhtuceophgvthgvrhdr vghishgvnhhtrhgruhhtsegvnhhtvghrphhrihhsvggusgdrtghomheqnecuggftrfgrth htvghrnhepleevheehueeiudeiteeitdekueetleefteejffeiffdugedvffdvffdtiedv ueeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepph gvthgvrhdrvghishgvnhhtrhgruhhtsegvnhhtvghrphhrihhsvggusgdrtghomh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 6 Jul 2021 13:56:13 -0400 (EDT) Subject: Re: BUG #17061: Impossible to query the fields of the tuple created by SEARCH BREADTH FIRST BY .. SET .. To: blo.talkto@gmail.com, pgsql-bugs@lists.postgresql.org References: <17061-dd7f4825b7da3a9d@postgresql.org> From: Peter Eisentraut Message-ID: <4a068167-37ed-3d6c-5ec5-c9b03cae84e6@enterprisedb.com> Date: Tue, 6 Jul 2021 19:56:10 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <17061-dd7f4825b7da3a9d@postgresql.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 17.06.21 13:44, PG Bug reporting form wrote: > -- So I try to get the "*DEPTH*" column but it fails with (I get the same > error with (breadth).id) : > -- > -- ERROR: CTE m does not have attribute 3 > > WITH RECURSIVE mtree(id, name) AS ( > SELECT id, name > FROM tree > WHERE id = 1 > UNION ALL > SELECT t.id, t.name > FROM tree AS t > INNER JOIN mtree AS m ON t.parent_id = m.id > ) SEARCH BREADTH FIRST BY id SET breadth > SELECT (breadth)."*DEPTH*" > FROM mtree m; We could put a workaround for this into expandRecordVariable() to handle the extra columns similar to what we have in markTargetListOrigin(), but it's still not going to work, because then you'll get ERROR: record type has not been registered This is similar to what you get now if you write something like ... ) SEARCH DEPTH FIRST BY id SET seq SELECT (seq[1]).* FROM mtree m; It's not really meant to be used that way. I'm not sure whether it's worth spending extra effort on. > -- The following works but feels a little hacky > > WITH RECURSIVE mtree(id, name) AS ( > SELECT id, name > FROM tree > WHERE id = 1 > UNION ALL > SELECT t.id, t.name > FROM tree AS t > INNER JOIN mtree AS m ON t.parent_id = m.id > ) SEARCH BREADTH FIRST BY id SET breadth > SELECT row_to_json(breadth) -> '*DEPTH*' > FROM mtree m; This works because it does not require type information for the fields in the row you're digging into (which is what the "registering" of the record type would accomplish).