Re: Assignment of valid collation for SET operations on queries with UNKNOWN types.

Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> writes:
> On Mon, Jan 23, 2017 at 9:56 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I've grepped the code for references to UNKNOWNOID and TYPTYPE_PSEUDO,
>> and I can't find any places where the behavior would change in a way
>> that we don't want. Basically it looks like we'd disallow UNKNOWN as
>> a domain base, a PL function argument or result, and a plpgsql local
>> variable; and all of those seem like good things from here.

> Thanks. I think this brings unknown in line with record, internal,
> void etc. and that's good. That's really where it should be.

> I thought this code in CreateCast would create problem.

Ah, I forgot to mention that: we'd also be disallowing creation of
casts to and from unknown. This is also a good thing.

> This means that the user can not create a cast to or from unknown
> type. But then there's following code in can_coerce_type()

Right, the system's notion of what to do with unknown is hard-wired.
We do not want people to get the idea that they can override it by
defining a cast. (Also, if anyone has done that, I don't think it
actually had any effect.)

> But I think we will have to watch for
> any such casts created by users in pg_dump and pg_upgrade. Similarly
> for transforms, range(?).

As I said to Michael w.r.t. the same point for domains, I doubt this
is worth spending cycles on to make a separate check for. It seems
pretty unlikely that anyone has actually done that, and if they did,
they'll still get a clean failure with an understandable message.

regards, tom lane