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

> david.g.johns...@gmail.com wrote: > > Allowing domains to be defined as not null at this point is simply something > that we don't support but don't error out upon in the interest of backward > compatibility. (IMO, the documentation is not this strongly worded.) It, as > you note, has some

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

On Sun, Jun 19, 2022 at 2:31 PM Bryn Llewellyn wrote: > It would be foolish, therefore, to define the target table for > "insert-select" using "CTAS where false". > SQL is a strongly typed language where the structure of the query output is determined without any consideration of whether said

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

Bryn Llewellyn 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's analysis is *sometimes* > clever

Outer joins and NULLs (old subject "ERROR: failed to find conversion function from key_vals_nn to record[]")

> b...@yugabyte.com wrote: > >> david.g.johns...@gmail.com wrote: >> >>> b...@yugabyte.com wrote: >>> >>> Can anybody show me an implementation of a realistic use case that follows >>> proper practice — like "every table must a