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 1m2xWu-0005lA-BC for pgsql-bugs@arkaria.postgresql.org; Mon, 12 Jul 2021 15:07:32 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1m2xWt-0007NW-9x for pgsql-bugs@arkaria.postgresql.org; Mon, 12 Jul 2021 15:07:31 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m2xWt-0007NO-3T for pgsql-bugs@lists.postgresql.org; Mon, 12 Jul 2021 15:07:31 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m2xWq-0003J3-PC for pgsql-bugs@lists.postgresql.org; Mon, 12 Jul 2021 15:07:30 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 16CF7OmO2949603; Mon, 12 Jul 2021 11:07:24 -0400 From: Tom Lane To: "David G. Johnston" cc: Andrew Kiellor , "pgsql-bugs@lists.postgresql.org" Subject: Re: BUG #17101: Inconsistent behaviour when querying with anonymous composite types In-reply-to: References: <17101-a6faa1f74b35062d@postgresql.org> <2947259.1626099364@sss.pgh.pa.us> Comments: In-reply-to "David G. Johnston" message dated "Mon, 12 Jul 2021 07:26:43 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2949601.1626102444.1@sss.pgh.pa.us> Date: Mon, 12 Jul 2021 11:07:24 -0400 Message-ID: <2949602.1626102444@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "David G. Johnston" writes: > Why is the multi-valued IN expression special here? I would not expect the > more-than-one element IN clause to obey different rules than a one element > IN clause > -- passing scenario - IN query with multiple anonymous composite types > SELECT * FROM table1 WHERE column1 IN ('(0)', '(0)'); Yeah, that's pretty weird and non-orthogonal. With multiple non-Var values on the RHS, transformAExprIn tries to make a ScalarArrayOpExpr, for which it has to infer an array type for the array RHS, which it does like this: /* * Try to select a common type for the array elements. Note that * since the LHS' type is first in the list, it will be preferred when * there is doubt (eg, when all the RHS items are unknown literals). */ allexprs = list_concat(list_make1(lexpr), rnonvars); scalar_type = select_common_type(pstate, allexprs, NULL, NULL); This is fishy for various reasons, but the performance advantages of ScalarArrayOpExpr are enough that we avert our eyes from the corner cases. (In practice, people don't tend to write IN lists with intentionally varying RHS types anyway.) Meanwhile, the single-element IN is handled exactly like "x = y". regards, tom lane