weird cast behavior in "IN (values)" clause

Lists: pgsql-hackers
From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: weird cast behavior in "IN (values)" clause
Date: 2011-07-06 02:10:23
Message-ID: 1309918036-sup-4092@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

I just came across this:

alvherre=# select * from pg_class where oid::regclass in ('foo');
ERROR: invalid input syntax for type oid: "foo"
LÍNEA 1: select * from pg_class where oid::regclass in ('foo');
^
alvherre=# select * from pg_class where oid::regclass in ('foo', 'foo');
relname | relnamespace | reltype | reloftype | relowner | relam | relfilenode | reltablespace | relpages | reltuples | reltoastrelid | reltoastidxid | relhasindex | relisshared | relpersistence | relkind | relnatts | relchecks | relhasoids | relhaspkey | relhasrules | relhastriggers | relhassubclass | relfrozenxid | relacl | reloptions
---------+--------------+---------+-----------+----------+-------+-------------+---------------+----------+-----------+---------------+---------------+-------------+-------------+----------------+---------+----------+-----------+------------+------------+-------------+----------------+----------------+--------------+--------+------------
foo | 2200 | 16448 | 0 | 10 | 0 | 16446 | 0 | 0 | 0 | 0 | 0 | t | f | p | r | 1 | 0 | f | t | f | f | f | 720 | |
(1 fila)

Not sure what to make of it.

(The reason I put the regclass cast in the oid instead of the other way
around is that I was trying a bunch of other tables, so it was
oid::regclass IN ('foo', 'bar', 'baz')
which is a lot easier to type than attaching a regclass cast to each
literal).

I am not sure why it would be valid to list two literals in the values
but not one.

--
Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: weird cast behavior in "IN (values)" clause
Date: 2011-07-06 04:24:09
Message-ID: 27136.1309926249@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> I am not sure why it would be valid to list two literals in the values
> but not one.

The discrepancy seems to be because transformAExprIn uses a different
type resolution method when there's more than one non-Var in the RHS.

Maybe we should apply select_common_type even when there's only one
RHS non-Var, even though we don't want to use a ScalarArrayOpExpr?

Curious that it's acted like this since 8.2 and nobody complained.

regards, tom lane