Re: BUG #14549: pl/pgsql parser

2017-02-19 17:41 GMT+01:00 Stefan Stefanov <stefanov(dot)sm(at)abv(dot)bg>:

> 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(at)sss(dot)pgh(dot)pa(dot)us
> >Относно: Re: [BUGS] BUG #14549: pl/pgsql parser
> >До: Wei Congrui <crvv(dot)mail(at)gmail(dot)com>
> >Изпратено на: 17.02.2017 18:54
>
> Wei Congrui <crvv(dot)mail(at)gmail(dot)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
>