Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> writes: > On Mon, Jan 23, 2017 at 9:56 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers