From: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
---|---|
To: | "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, krking(at)zju(dot)edu(dot)cn, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #17477: A crash bug in transformValuesClause() |
Date: | 2022-05-09 18:15:04 |
Message-ID: | CAD21AoDuQYcLmmPGe8-0ZoU=2VgvYAh1godFwYoNbSXe6TP0Qg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Tue, May 10, 2022 at 2:20 AM Jonathan S. Katz <jkatz(at)postgresql(dot)org> wrote:
>
> On 5/9/22 11:25 AM, Tom Lane wrote:
> > Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> writes:
> >> It seems like transformValuesClause() cannot handle properly the value
> >> clause having a relation that has an empty column. Should we raise an
> >> error in this case?
> >
> > Given that we try to support zero-column relations, I'm not sure why
> > we'd insist on disallowing zero-column VALUES. I think the problem
> > is that the code in transformValuesClause needs to be tweaked to
> > make that work. The attached quick hack seems to do the trick.
>
> Agree with the reasoning.
>
> Confirmed reproducing the crash and that this fixes it. I did a short
> double-take on the error message:
>
> ERROR: subquery must return only one column
>
> but it is accurate, given this is what the subquery must do, and zero !=
> one.
Agreed. I've also confirmed that the patch fixes this issue and passed
the regression tests.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-05-09 18:33:38 | Re: BUG #17477: A crash bug in transformValuesClause() |
Previous Message | Tom Lane | 2022-05-09 17:42:02 | Re: BUG #17477: A crash bug in transformValuesClause() |