Content-Type: multipart/mixed; boundary="------------qg8YolNLHy5borK3HIabGacd"
Message-ID: <332f0e30-f90a-4e47-b668-b53f649c244f@gmail.com>
Date: Mon, 19 Aug 2024 13:23:51 +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 <tgl@sss.pgh.pa.us>, Richard Guo <guofenglinux@gmail.com>
Cc: pgsql-bugs@lists.postgresql.org
References: <18576-9feac34e132fea9e@postgresql.org>
 <CAMbWs49gOeyotM7riJ-q_NgLgfA6-3z7DffnR71kSyaHTkh2ig@mail.gmail.com>
 <2336091.1723137115@sss.pgh.pa.us> <2493069.1723149304@sss.pgh.pa.us>
 <CAMbWs4_Au2i+p2MbZ8nNB_QQXrFy65CXNeJL11j2WJbNW18fHQ@mail.gmail.com>
 <2548861.1723174234@sss.pgh.pa.us> <2799439.1723217127@sss.pgh.pa.us>
Content-Language: en-US
From: Andrei Lepikhov <lepihov@gmail.com>
In-Reply-To: <2799439.1723217127@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/332f0e30-f90a-4e47-b668-b53f649c244f%40gmail.com>
Precedence: bulk

This is a multi-part message in MIME format.
--------------qg8YolNLHy5borK3HIabGacd
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 9/8/2024 17:25, Tom Lane wrote:
> I wrote:
>> Richard Guo <guofenglinux@gmail.com> writes:
>>> Agreed.  Do you think it would be helpful to add some assertions to
>>> verify the plan type?
> 
>> I thought about that but didn't experiment with it.  I wonder whether
>> it'd just make the code more fragile.  Still, it might be useful to
>> verify that things are happening as we expect.
> 
> After sleeping on it, I elected to add the Asserts as suggested,
> except in v12 where they'd have had to look different.  That's
> not strictly a matter of laziness: v12's next release will be its
> last, and I've been burned often enough to become very hesitant
> about pushing even slightly-questionable code into an EOL release.
Thanks for pushing this!

But could you change this code a little bit?
I reported this issue a year ago. At that time, it was triggered by the 
CustomScan node [1]. I haven't found the solution there [2]. Your code 
looks like a good tradeoff, and if you slightly change the code (like in 
the attachment), it allows CustomScan to survive such cases.

[1] 
https://www.postgresql.org/message-id/3933834e-b657-4ad1-bf4e-5f3fbba7ba14%40app.fastmail.com
[2] 
https://www.postgresql.org/message-id/0cbbd87e-1b57-4b7e-9825-19a6fb2f8670%40postgrespro.ru

-- 
regards, Andrei Lepikhov

--------------qg8YolNLHy5borK3HIabGacd
Content-Type: text/plain; charset=UTF-8; name="minor_fix.diff"
Content-Disposition: attachment; filename="minor_fix.diff"
Content-Transfer-Encoding: base64

ZGlmZiAtLWdpdCBhL2NvbnRyaWIvTWFrZWZpbGUgYi9jb250cmliL01ha2VmaWxlCmluZGV4
IGFiZDc4MGYyNzcuLmM2OGFhN2JlMDAgMTAwNjQ0Ci0tLSBhL2NvbnRyaWIvTWFrZWZpbGUK
KysrIGIvY29udHJpYi9NYWtlZmlsZQpAQCAtNiw2ICs2LDcgQEAgaW5jbHVkZSAkKHRvcF9i
dWlsZGRpcikvc3JjL01ha2VmaWxlLmdsb2JhbAogCiBTVUJESVJTID0gXAogCQlhbWNoZWNr
CQlcCisJCXBnX2V4dGVuc2lvbglcCiAJCWF1dGhfZGVsYXkJXAogCQlhdXRvX2V4cGxhaW4J
XAogCQliYXNpY19hcmNoaXZlCVwKZGlmZiAtLWdpdCBhL3NyYy9iYWNrZW5kL3V0aWxzL2Fk
dC9ydWxldXRpbHMuYyBiL3NyYy9iYWNrZW5kL3V0aWxzL2FkdC9ydWxldXRpbHMuYwppbmRl
eCA0MDM5ZWUwZGY3Li4yNzI4ZTM1MTA1IDEwMDY0NAotLS0gYS9zcmMvYmFja2VuZC91dGls
cy9hZHQvcnVsZXV0aWxzLmMKKysrIGIvc3JjL2JhY2tlbmQvdXRpbHMvYWR0L3J1bGV1dGls
cy5jCkBAIC03OTE0LDcgKzc5MTQsOCBAQCBnZXRfbmFtZV9mb3JfdmFyX2ZpZWxkKFZhciAq
dmFyLCBpbnQgZmllbGRubywKIAkJCQkJewogCQkJCQkJY2hhcgkgICAqZHVtbXlfbmFtZSA9
IHBhbGxvYygzMik7CiAKLQkJCQkJCUFzc2VydChkcG5zLT5wbGFuICYmIElzQShkcG5zLT5w
bGFuLCBSZXN1bHQpKTsKKwkJCQkJCUFzc2VydChkcG5zLT5wbGFuICYmIChJc0EoZHBucy0+
cGxhbiwgUmVzdWx0KSB8fAorCQkJCQkJCQkJCQkgIElzQShkcG5zLT5wbGFuLCBDdXN0b21T
Y2FuKSkpOwogCQkJCQkJc25wcmludGYoZHVtbXlfbmFtZSwgMzIsICJmJWQiLCBmaWVsZG5v
KTsKIAkJCQkJCXJldHVybiBkdW1teV9uYW1lOwogCQkJCQl9CkBAIC04MDQ1LDcgKzgwNDYs
OCBAQCBnZXRfbmFtZV9mb3JfdmFyX2ZpZWxkKFZhciAqdmFyLCBpbnQgZmllbGRubywKIAkJ
CQkJewogCQkJCQkJY2hhcgkgICAqZHVtbXlfbmFtZSA9IHBhbGxvYygzMik7CiAKLQkJCQkJ
CUFzc2VydChkcG5zLT5wbGFuICYmIElzQShkcG5zLT5wbGFuLCBSZXN1bHQpKTsKKwkJCQkJ
CUFzc2VydChkcG5zLT5wbGFuICYmIChJc0EoZHBucy0+cGxhbiwgUmVzdWx0KSB8fAorCQkJ
CQkJCQkJCQkgIElzQShkcG5zLT5wbGFuLCBDdXN0b21TY2FuKSkpOwogCQkJCQkJc25wcmlu
dGYoZHVtbXlfbmFtZSwgMzIsICJmJWQiLCBmaWVsZG5vKTsKIAkJCQkJCXJldHVybiBkdW1t
eV9uYW1lOwogCQkJCQl9Cg==

--------------qg8YolNLHy5borK3HIabGacd--