From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | sulfinu(at)gmail(dot)com |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: Aggregation results with json(b)_agg and array_agg in a SELECT with OUTER JOIN |
Date: | 2023-05-19 20:14:07 |
Message-ID: | CAKFQuwa_S4GzcHvgJ2B24yWoZDVD_Fwa-4cwBaNi8QrUYbQybw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Fri, May 19, 2023 at 9:59 AM <sulfinu(at)gmail(dot)com> wrote:
> I've adjusted the statements so that you can clearly see that *there is a
> difference* between a missing outer-joined entity and its columns being
> actually set to NULL:
> Therefore, *it is a bug*.
>
Yep, the output of a left join, so far as the implicit composite (row?)
type produced for the nullable relation is concerned, has a form that
depends on whether or not a match was found. i.e., the system produces
null::b for a non-match. Its a reasonable way to express "no match
present". And in the presence of an aggregate checking for {NULL} versus
{(,)} to differentiate the two cases is actually doable (see NULLIF())
A bug is "something that isn't working as designed" but you haven't said
what design you are taking to be authoritative. Different queries and data
producing different outputs is something that usually is beneficial.
David J.
From | Date | Subject | |
---|---|---|---|
Next Message | 396934406 | 2023-05-20 02:06:43 | ERROR: CREATE DATABASE cannot be executed within a pipeline |
Previous Message | Tom Lane | 2023-05-19 19:55:02 | Re: initdb faild to initialize full text search dictionaries |