Re: BUG #14549: pl/pgsql parser

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

> Thanks Pavel.
> Different columns and data types tolerance is ok, however what about wrong
> and meaningless syntax?
>

There was a discussion about more restrictivity or about different syntax.

More restrict behave can breaks compatibility - now we have good enough
tools, so compatibility break is not necessary.

Regards

Pavel

> Best,
> Stefan
>
>
>
> >-------- Оригинално писмо --------
> >От: Pavel Stehule pavel(dot)stehule(at)gmail(dot)com
> >Относно: Re: [BUGS] BUG #14549: pl/pgsql parser
> >До: stefanov(dot)sm(at)abv(dot)bg
> >Изпратено на: 17.02.2017 11:19
>
> Hi
>
> 2017-02-17 8:58 GMT+01:00 <stefanov(dot)sm(at)abv(dot)bg>:
>
> The following bug has been logged on the website:
>
> Bug reference: 14549
> Logged by: Stefan Stefanov
> Email address: stefanov(dot)sm(at)abv(dot)bg
> PostgreSQL version: 9.5.3
> Operating system: Red Hat, 64 bit
> Description:
>
> Hi all,
> I found (the hard way) that in pl/pgsql SELECT INTO statement a syntax
> error
> may remain unnoticed.
> This simple example works as expected and produces '1, 2, 3' notice.
>
> DO language plpgsql
> $$
> DECLARE
> vara integer;
> varb integer;
> varc integer;
> BEGIN
> SELECT 1, 2, 3 INTO vara, varb, varc;
> RAISE NOTICE '% % %', vara, varb, varc;
> END;
> $$;
>
> However if you omit a comma (or even replace the comma with AS) between
> varb
> and varc in the INTO list then no syntax error is produced and the
> resulting
> notice is '1 2 <NULL>'.
>
> DO language plpgsql
> $$
> DECLARE
> vara integer;
> varb integer;
> varc integer;
> BEGIN
> SELECT 1, 2, 3 INTO vara, varb AS varc;
> RAISE NOTICE '% % %', vara, varb, varc;
> END;
> $$;
>
> A few more clearly erratic combinations of SELECT expressions and the INTO
> list also 'work' and issue misleading results.
> Same in functions. For me it produced a bug that was difficult to see and
> track.
>
> Best,
> Stefan
>
>
> It is not a bug - plpgsql is designed be tolerant to different columns and
> data types in left and right part of assignment.
>
> You can use some tools for easy detecting these issues:
>
> 1. plpgsql_check https://github.com/okbob/plpgsql_check - it is available
> in community repository
> 2. prepared extra_checks https://commitfest.postgresql.org/13/962/
>
> Regards
>
> Pavel
>
>
>
>
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs
>
>
>