| From: | Jeevan Chalke <jeevan(dot)chalke(at)enterprisedb(dot)com> |
|---|---|
| To: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | PL/pgSQL: apply the too_many_rows extra check to EXECUTE ... INTO |
| Date: | 2026-10-30 11:42:16 |
| Message-ID: | CAM2+6=WikOK3t=LN+jhzNBchrO3uy0tzVPuPygnz9yoUTwnb6Q@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
The documentation for plpgsql.extra_warnings / plpgsql.extra_errors says
that the too_many_rows check will "*check if a given query returns more
than one row when an INTO clause is used*" *[1]*. Only static SQL
statements implement this (exec_stmt_execsql()). exec_stmt_dynexecute()
only looks at STRICT, so EXECUTE ... INTO silently uses the first row and
nothing is reported:
set plpgsql.extra_warnings = 'too_many_rows';
do $$ declare x int;
begin
execute 'select g from generate_series(1,2) g' into x;
end $$;
DO
The same statement written as static SQL does warn (or fail, with
extra_errors).
The attached patch computes too_many_rows_level in exec_stmt_dynexecute()
the same way exec_stmt_execsql() does, and reports at that level when more
than one row comes back and STRICT was not specified. With it:
WARNING: query returned more than one row
HINT: Make sure the query returns a single row, or use LIMIT 1.
DO
and with plpgsql.extra_errors the same message is raised as an ERROR.
Checking costs nothing extra here, since EXECUTE already fetches all the
rows (no row limit is passed to SPI).
While there, I added the "Make sure the query returns a single row, or use
LIMIT 1." hint to the error raised for EXECUTE ... INTO STRICT, so that it
matches the error for static SQL. This changes the expected output of
three existing STRICT tests, which now show the HINT line.
The new tests are in the "runtime extra checks" section of plpgsql.sql and
cover EXECUTE ... INTO with both extra_warnings and extra_errors.
This is a behavior change: someone who has too_many_rows in extra_errors
may start getting errors from EXECUTE ... INTO statements that used to
pass. So I think this should go to master only (or v19, as it is yet to
release), but I'd like to hear what others think.
Thanks
*[1]
https://www.postgresql.org/docs/current/plpgsql-development-tips.html#PLPGSQL-EXTRA-CHECKS
<https://www.postgresql.org/docs/current/plpgsql-development-tips.html#PLPGSQL-EXTRA-CHECKS>*
--
*Jeevan Chalke*
*Senior Principal Engineer, Engineering Manager*
*Product Development*
| Attachment | Content-Type | Size |
|---|---|---|
| v1-0001-Apply-the-too_many_rows-extra-check-to-EXECUTE-.-.patch | application/octet-stream | 5.7 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | vignesh C | 2026-10-30 11:48:34 | Re: Hash index: stop registering pin-only bucket pages in WAL (remove REGBUF_NO_CHANGE) |
| Previous Message | Ashutosh Bapat | 2026-10-30 11:17:33 | Call CalculateShmemSize() only once |