"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Mon, Mar 19, 2018 at 8:33 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Another one that seems to fall into the "fairly large-scale work" would be
> the:
> ERROR: more than one row returned by a subquery used as an expression
> (that's it, nothing else prints in psql when I run the offending query -
> using "--echo-all" to at least see what query I sent caused the issue)
Yeah, this falls into the general category of unlocalized run-time errors.
I still think that emitting an error cursor would be a general-purpose
answer that would improve the user experience for this and many other
cases. You could imagine specific behaviors that would be more optimal
for this specific error report, but the approach of solving this issue
one error at a time doesn't scale even a little bit.
> Printing out the offending expression would be nice if possible - printing
> the set (size > 1) of values that were returned would probably help as
> well, though usually the problem data is in a where clause while the set
> would contain target list data - and its those where clause items that
> matter more. In the case of a correlated subquery exhibiting this problem
> the outer query vars being passed in is what would be most helpful.
IIRC, this error is thrown as soon as we get a second row out of the
subquery; we don't know what the ultimate result-set size would be,
and I rather doubt that finding that out would be helpful very often.
Nor does it seem like figuring out how to identify the parameter values
passed down to the subquery (if any) would really repay the effort.
The set that the executor thinks it's passing down might not have that
much to do with what the user thinks the query is doing.
regards, tom lane
