BUG #17101: Inconsistent behaviour when querying with anonymous composite types - Mailing list pgsql-bugs

From David G. Johnston
Subject BUG #17101: Inconsistent behaviour when querying with anonymous composite types
Date
Msg-id CAKFQuwY0QBhO_NrXs-Zf_Hy2Xy5mu8eMrYXN9_araRjjNSpK_w@mail.gmail.com
Whole thread Raw
In response to Re: BUG #17101: Inconsistent behaviour when querying with anonymous composite types  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #17101: Inconsistent behaviour when querying with anonymous composite types  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On Monday, July 12, 2021, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Andrew Kiellor <akiellor@gmail.com> writes:
> Sorry I omitted the output. It is as follows:

> psql:test.sql:14: ERROR:  input of anonymous composite types is not implemented
> LINE 1: SELECT * FROM table1 WHERE column1 = '(0)';
>                                              ^

I think this is operating as designed.  I agree it'd be slightly more
convenient if the parser would infer that the RHS must be of the same
type as the LHS, but shoehorning that into the existing system design
seems problematic. 


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)');

David J.

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #17101: Inconsistent behaviour when querying with anonymous composite types
Next
From: Tom Lane
Date:
Subject: Re: BUG #17101: Inconsistent behaviour when querying with anonymous composite types