2014/1/12 Florian Pflug <f...@phlo.org> > On Jan12, 2014, at 06:51 , Marko Tiikkaja <ma...@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. Regards Pavel > > best regards, > Florian Pflug > > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >
