Re: plpgsql.consistent_into

Поиск
Список
Период
Сортировка
От Florian Pflug
Тема Re: plpgsql.consistent_into
Дата
Msg-id 2FA76496-0530-4EFC-B1DF-53078CE614A6@phlo.org
обсуждение исходный текст
Ответ на plpgsql.consistent_into  (Marko Tiikkaja <marko@joh.to>)
Ответы Re: plpgsql.consistent_into  (Marko Tiikkaja <marko@joh.to>)
Re: plpgsql.consistent_into  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-hackers
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
annoyingfootguns in PL/PgSQL: the behaviour of SELECT .. INTO when the query returns more than one row.  Some of you
mightknow 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
either0 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.

best regards,
Florian Pflug




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: Standalone synchronous master
Следующее
От: Marko Tiikkaja
Дата:
Сообщение: Re: plpgsql.consistent_into