From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Bryn Llewellyn <bryn(at)yugabyte(dot)com> |
Cc: | "Peter J(dot) Holzer" <hjp-pgsql(at)hjp(dot)at>, pgsql-general list <pgsql-general(at)lists(dot)postgresql(dot)org>, Tom Lane PostgreSQL <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: Outer joins and NULLs (old subject "ERROR: failed to find conversion function from key_vals_nn to record[]") |
Date: | 2022-06-20 01:10:38 |
Message-ID: | CAKFQuwYUGrGSFhVwE2y-tSXPERXVpwnv56_G2qSKuuP9=wsA=w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sun, Jun 19, 2022 at 2:31 PM Bryn Llewellyn <bryn(at)yugabyte(dot)com> 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 query returns zero,
one, or many rows. Because of this property it is entirely consistent that
a CTAS produces a table even if the query execution produces zero rows.
That CTAS chooses to not try and produce constraints on the newly created
table by inferring them from the underlying query seems like a reasonable
trade-off between functionality and effort. It simply stops at "data
types" and doesn't care for how any given one is implemented. That domains
have constraints is incidental to the entire design.
Allowing domains to be defined as not null at this point is simply
something that we (IMO, the documentation is not this strongly worded)
don't support but don't error out upon in the interest of backward
compatibility. It, as you note, has some corner-case bugs. You can avoid
those bugs by simply not using a non-null constraint as suggested.
As for the "same source" optimization: the documentation reads - "For
example, this can happen in an outer-join query,...", the bug-fix here is
to simply add this situation as a second example. However, it is
reasonably considered correct that a record you just read from a table
should be able to be written back to said table unchanged. The "error" is
that we allowed the record to exist in the first place, but we absolved
ourselves of responsibility with the caveats on the CREATE DOMAIN page.
Subsequent consequences of that mis-use are likewise attributed to said
mis-use and are on the user's head for allowing their code to produce the
problematic behavior.
At most we should probably go from saying "Best practice therefore..." to
"We no longer support setting a not null constraint on a domain but will
not error in the interest of not breaking existing uses that are careful to
avoid the problematic corner-cases".
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | Bryn Llewellyn | 2022-06-20 02:45:09 | Re: '{"x": 42, "y": null}'::jsonb != '{"x": 42}'::jsonb ... Really? |
Previous Message | Tom Lane | 2022-06-19 23:28:35 | Re: Outer joins and NULLs (old subject "ERROR: failed to find conversion function from key_vals_nn to record[]") |