The documentation keeps the door open. Two compatible suggestions:
SET plpgsql_syntax TO strict; -- with loose as default
The parser becomes strict about the placement of INTO (as the manual hints) and about the number and type of SELECT output columns matching the number of INTO target variables.
We talked about changing behave by GUC, and this is usually disallowed.
But new extra check can raise warning, so this behave should not be a issue.
Regards
Pacel
A warning and a hint rather then an exception to keep backwards compatibility
Sincerely, Stefan
>-------- Оригинално писмо -------- >От: Tom Lane tgl@sss.pgh.pa.us >Относно: Re: [BUGS] BUG #14549: pl/pgsql parser >До: Wei Congrui <crvv.mail@gmail.com> >Изпратено на: 17.02.2017 18:54
Wei Congrui <crvv.mail@gmail.com> writes: > In the document, > https://www.postgresql.org/docs/9.6/static/plpgsql-statements.html#PLPGSQL-STATEMENTS-SQL-ONEROW > "If a row or a variable list is used as target, the query's result > columns must exactly match the structure of the target as to > number and data types, or else a run-time error occurs. When > a record variable is the target, it automatically configures itself > to the row type of the query result columns."
> I think this is a bug according to the document.
I don't think that's the relevant point. What is relevant is the next paragraph:
"The INTO clause can appear almost anywhere in the SQL command. Customarily it is written either just before or just after the list of select_expressions in a SELECT command, or at the end of the command for other command types. It is recommended that you follow this convention in case the PL/pgSQL parser becomes stricter in future versions."
What's happening in Stefan's example
SELECT 1, 2, 3 INTO vara, varb AS varc;
is that "INTO vara, varb" is pulled out as being the INTO clause, and what's left is
SELECT 1, 2, 3 AS varc;
which is a perfectly legal SQL statement so no error is reported.
To make this throw an error, we'd need to become stricter about the placement of INTO (as the manual hints), or become stricter about the number of SELECT output columns matching the number of INTO target variables, or possibly both. Any such change would doubtless draw complaints from people whose code worked fine before. It might be a good idea anyway, but selling backwards-compatibility breakage to the Postgres community is usually a hard sell.
