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

On Tue, Jan 24, 2017 at 1:26 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I wrote:
>> Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com> writes:
>>> UNKNOWN is not exactly a pseudo-type.
>
>> Well, as I said to Michael just now, I think we should turn it into one
>> now that we're disallowing it in tables, because "cannot be used as a
>> table column" is more or less the definition of a pseudotype.
>
> I experimented with this, and it actually doesn't seem to be any harder
> than the attached: there's one type_sanity query that changes results,
> and otherwise all the regression tests pass.

Indeed.

> 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.

This has the merit to fix the ugly check in heap.c, so you may want to
merge both patches. At least I'd suggest to do so.

> Have not checked the docs.

Just looked at that.

As unknown is a pseudo type, I don't think you need
TYPCATEGORY_UNKNOWN in pg_type.h or even the mention to the unknown
type in catalogs.sgml as that becomes a pseudo-type.

The table of Pseudo-Types needs to be updated as well with unknown in
datatype.sgml.

For domains, it is still necessary to add an extra check in pg_upgrade
and fail the upgrade if one of the domains declared uses the type
unknown. Domains are not listed in pg_class, and are only present in
pg_type. If you don't do that, the binary restore would just fail.
--
Michael