Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> writes:
> On Mon, Jan 23, 2017 at 9:56 PM, Tom Lane <tgl@sss.pgh.pa.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