Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sg7sg-00Fcfj-Ei for pgsql-bugs@arkaria.postgresql.org; Mon, 19 Aug 2024 19:17:30 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sg7rf-001pLs-P1 for pgsql-bugs@arkaria.postgresql.org; Mon, 19 Aug 2024 19:16:28 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sg7rf-001pLj-GF for pgsql-bugs@lists.postgresql.org; Mon, 19 Aug 2024 19:16:28 +0000 Received: from mail-wm1-x334.google.com ([2a00:1450:4864:20::334]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sg7rc-000UfP-Iz for pgsql-bugs@lists.postgresql.org; Mon, 19 Aug 2024 19:16:27 +0000 Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-42812945633so41219355e9.0 for ; Mon, 19 Aug 2024 12:16:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724094984; x=1724699784; darn=lists.postgresql.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=EtATcYJrssehWSSqNNN2+Njfu35CBGPhJ3DZlJAxj5Q=; b=QuvlVbwNxxZRPRE1lKPYSRcBMuZ9m4Bc8qC0N87NlmAmMlXSMxsAd4YQN2Dwy8JqOv hutlChFDVu2UT+QIRT1OvmKdp3EsShKATbo2WFYP72XZt/OFG+2uszK/IHR4K8RHDjqz +TG5ly1MYmXKEfmCGBW7JW7vVTVmUIy3XLYx3HYhiLI0KIj+E16o0E2kvQ5pkrWf+Tlb HlqEljHsG0U2PCHJOuQtFvRaFv4Jw4y30vQsZBPwZQOZREDmkS9VSENBcCUMxvhuCbv2 0Dr7gY2CZk90ZbtaHYBA501k3UTK4fWJh0VT0BcrnM8ndB2nflugpC+DX/X+mi2YmZQ+ LuFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724094984; x=1724699784; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=EtATcYJrssehWSSqNNN2+Njfu35CBGPhJ3DZlJAxj5Q=; b=k8F0YU2IUxJfflpJ9A/6oPL5jxUznJ3k+dW1Dx5LyeeXIoAk4O8u14e/TH/Nc5t0Ki zP9deK8yLWU04Rhx0cyDUW2TgUBbBF8iMSxhQk38ZL9bBCVMIV1KepvBn7I+C6Hm+FkM u9q55jjBSeabETPJFXSbSuaBptrcKvgmIPppJM+yPKKQB+m99xwldg4eO7SsqAOg9+8M NSA4x5IvSa1mgXmGQuoUM0qZGh5OPYpjw8fRfIYazY6XlRfw2fTVIhpxCzqazGsAPJpE BM1Y7rVNTTchmqTaMFuumdXw2Cc03e+FGJDHlbJ/gM8pw8rLBLfnEyAxJ40ja+nCtFgl OAbQ== X-Forwarded-Encrypted: i=1; AJvYcCX2MC0J+UVIh7EabBb3CNVrQJTqsrdlMzV0VTaU0OkgNA1XahiomC4JbDrxSZPfJn9spN+UlkpGZ9qvEWQ3jkwESMrKbwsokiPIev/m3Rg6 X-Gm-Message-State: AOJu0YyYc4YaFrlMxgBFyeBHJ6YQSmAIFgxSMXUYLtieR6MAwXFZyU14 GycErHgjsuB7AoZXYq5wgPIfnH0wJuLZ2xf8kpC10chOgUv3bkdo X-Google-Smtp-Source: AGHT+IEZ119lxlrAb1ChogPk9DS1ZaY0E0TRW8w3DJmV369Ead8kCRuNGC+MqXfjr99QZenkrFxmYw== X-Received: by 2002:a7b:c5d8:0:b0:426:6921:e3e5 with SMTP id 5b1f17b1804b1-429ed7cf042mr83093425e9.24.1724094984085; Mon, 19 Aug 2024 12:16:24 -0700 (PDT) Received: from ?IPV6:2a0c:5a83:4c09:9d00:ed42:c0b8:e522:cb22? ([2a0c:5a83:4c09:9d00:ed42:c0b8:e522:cb22]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-429ed7841a1sm117817255e9.29.2024.08.19.12.16.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 19 Aug 2024 12:16:23 -0700 (PDT) Message-ID: <7f8bfe01-bc5f-4a93-bcd6-b06e7c24f804@gmail.com> Date: Mon, 19 Aug 2024 21:16:22 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: BUG #18576: Using EXPLAIN (VERBOSE) in information_schema.element_types returns ERROR: failed to find plan for To: Tom Lane Cc: Richard Guo , pgsql-bugs@lists.postgresql.org References: <18576-9feac34e132fea9e@postgresql.org> <2336091.1723137115@sss.pgh.pa.us> <2493069.1723149304@sss.pgh.pa.us> <2548861.1723174234@sss.pgh.pa.us> <2799439.1723217127@sss.pgh.pa.us> <332f0e30-f90a-4e47-b668-b53f649c244f@gmail.com> <1385302.1724085401@sss.pgh.pa.us> <5e129a8e-5b8d-4a61-9776-59be99a2c14f@gmail.com> <1390980.1724088410@sss.pgh.pa.us> Content-Language: en-US From: Andrei Lepikhov In-Reply-To: <1390980.1724088410@sss.pgh.pa.us> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 19/8/2024 19:26, Tom Lane wrote: > Andrei Lepikhov writes: >> On 19/8/2024 18:36, Tom Lane wrote: >>> This seems like it's making assumptions it shouldn't about what >>> CustomScan does. If there's an argument for doing this, it should >>> be added to the adjacent comments. > The main reason I'm being sticky about this is that if we need to > allow CustomScan, then it seems likely that we also need to allow > ForeignScan, and maybe some other things, and then I start to > wonder if we should have any assertion at all about the child > plan type. So I want to actually understand what is the scenario > in which this will happen. I understand your point — the origins of ForeignScan and CustomScan are the same. However, we also have a difference: CustomScan can be executed locally and sometimes may allow volatile functions, CTE, and many other things in the underlying subtree. That's why we can't replay some cases with ForeignScan stuff. But ok, it make sense. I'll try to reproduce the case by employing ForeignScan. -- regards, Andrei Lepikhov