Re: plpgsql.consistent_into

2014/1/12 Florian Pflug <fgp(at)phlo(dot)org>

> On Jan12, 2014, at 06:51 , Marko Tiikkaja <marko(at)joh(dot)to> wrote:
> > I would humbly like to submit for your consideration my proposal for
> alleviating pain caused by one of the most annoying footguns in PL/PgSQL:
> the behaviour of SELECT .. INTO when the query returns more than one row.
> Some of you might know that no exception is raised in this case (as
> opposed to INSERT/UPDATE/DELETE .. INTO, all of them yielding
> TOO_MANY_ROWS), which can hide subtle bugs in queries if during testing the
> query always returns only one row or the "correct" one happens to be picked
> up every time. Additionally, the row_count() after execution is always
> going to be either 0 or 1, so even if you want to explicitly guard against
> potentially broken queries, you can't do so!
> >
> > So I added the following compile-time option:
> >
> > set plpgsql.consistent_into to true;
>
> I don't think a GUC is the best way to handle this. Handling
> this via a per-function setting similar to #variable_conflict would
> IMHO be better.So a function containing
>
> #into_surplus_rows error
>
> would complain whereas
>
> #into_surplus_rows ignore_for_select
>
> would leave the behaviour unchanged.
>

There is GUC for variable_conflict already too. In this case I would to
enable this functionality everywhere (it is tool how to simply eliminate
some kind of strange bugs) so it needs a GUC.

We have GUC for plpgsql.variable_conflict three years and I don't know
about any problem.

Regards

Pavel

>
> best regards,
> Florian Pflug
>
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>