Re: Outer joins and NULLs (old subject "ERROR: failed to find conversion function from key_vals_nn to record[]") - Mailing list pgsql-general

From Tom Lane
Subject Re: Outer joins and NULLs (old subject "ERROR: failed to find conversion function from key_vals_nn to record[]")
Date
Msg-id 2287377.1655681315@sss.pgh.pa.us
Whole thread Raw
In response to Outer joins and NULLs (old subject "ERROR: failed to find conversion function from key_vals_nn to record[]")  (Bryn Llewellyn <bryn@yugabyte.com>)
List pgsql-general
Bryn Llewellyn <bryn@yugabyte.com> writes:
> Self-evidently, a view does *not* inherit constraints from the columns of its base table(s).

Check.

> A view on a single table doesn't necessarily inherit the data types of its base table's columns. Rather, the view
compilation'sanalysis is *sometimes* clever enough to notice when a projected column might have a NULL even when the
basecolumn doesn't allow NULLs. In this case, if the base column's data type is (in my example) the domain "text_nn",
thenthe corresponding column in the view is given the data type plain "text". My test that uses a single table shows
this.

This is nonsense.  The parser does not account for domain constraints in
that way.  It would be incorrect to do so, because then the view's data
types could need to change as a consequence of adding/dropping domain
constraints.  I think that your result is actually just an illustration
of the rules in
    https://www.postgresql.org/docs/current/typeconv-union-case.html
about how the output type of a CASE expression is determined ---
specifically, that domains are smashed to base types as soon as
the CASE arms are discovered to not be all of the same type.

            regards, tom lane



pgsql-general by date:

Previous
From: Thomas Kellerer
Date:
Subject: Re: '{"x": 42, "y": null}'::jsonb != '{"x": 42}'::jsonb ... Really?
Next
From: "David G. Johnston"
Date:
Subject: Re: Outer joins and NULLs (old subject "ERROR: failed to find conversion function from key_vals_nn to record[]")