On 2025-Apr-04, Tom Lane wrote:
> However ... it's possible that this isn't the stupidest, most
> brute-force code in Postgres, but I'll wager it's in the top ten.
> Is it really necessary to transform the subquery twice just to
> produce this error? It seems like the constructed EXPR_SUBLINK
> should produce the same error all by itself. I tried nuking this
> whole stanza to see whether that would happen, and then there are a
> couple of regression test cases that don't produce the same results.
> But I feel like it could be made to work with a bit more thought.
Ugh, yeah, this is really dumb. This quick-and-dirty patch (not final
form) gets us halfway there, by checking the targetlist after
transforming the query. I think this is the behavior we want, although
it's a bit scary that we have so few test cases for this.
Anyway, if we only do this, this query from the regression tests still
doesn't work the way we want:
SELECT JSON_ARRAY(SELECT FROM (VALUES (1)) foo(i));
It causes an error to be raised _during_ transformation, namely
+ERROR: table "q" has 0 columns available but 1 columns specified
which we'd like to report differently. I think we want to verify the
targetlist length of ctor->query before transformation, but I'm not sure
exactly how, yet.
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
