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.
- 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.
regards, tom lane