On Jan12, 2014, at 06:51 , Marko Tiikkaja <marko@joh.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.
