Re: BUG #17101: Inconsistent behaviour when querying with anonymous composite types

Andrew Kiellor <akiellor(at)gmail(dot)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. The record_eq operator doesn't actually require
that its inputs be of identical composite types, only compatible ones.
To continue your example:

regression=# CREATE TYPE type2 AS (xyz int);
CREATE TYPE
regression=# SELECT * FROM table1 WHERE column1 = '(0)'::type2;
column1
---------
(0)
(1 row)

regression=# CREATE TYPE type3 AS (x float);
CREATE TYPE
regression=# SELECT * FROM table1 WHERE column1 = '(0)'::type3;
ERROR: cannot compare dissimilar column types integer and double precision at record column 1

So if the parser assumed that the inputs must be of the same composite
type, it'd be exceeding its authority, and would likely cause queries
that work today to start failing.

The back story here is that type "record" isn't really a polymorphic
type, though it behaves similarly to those types in some ways. If we
were designing in a green field it'd make sense to treat "record"
according to the polymorphism rules. But we're not; "record" is way
older than the polymorphics so it has various unique idiosyncrasies.
The one that's relevant here is that an input argument that's declared
to be "record" isn't required to be the same composite type as another
argument also declared as "record".

regards, tom lane