plpgsql.consistent_into

Поиск
Список
Период
Сортировка
От Marko Tiikkaja
Тема plpgsql.consistent_into
Дата
Msg-id 52D22D48.2090704@joh.to
обсуждение исходный текст
Ответы Re: plpgsql.consistent_into  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: plpgsql.consistent_into  (Florian Pflug <fgp@phlo.org>)
Re: plpgsql.consistent_into  (Marti Raudsepp <marti@juffo.org>)
Список pgsql-hackers
Greetings fellow elephants,

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;

create or replace function footest() returns void as $$
declare
x int;
begin
   -- too many rows
   select 1 from foo into x;
end$$ language plpgsql;

select footest();
ERROR:  query returned more than one row

It defaults to false to preserve full backwards compatibility.  Also
turning it on makes the executor try and find two rows, so it might have
an effect on performance as well.  The patch, as currently written, also
changes the behaviour of EXECUTE .. INTO, but I don't feel strongly
about whether that should be affected as well or not.


Regards,
Marko Tiikkaja

Вложения

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

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: array_length(anyarray)
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: plpgsql.consistent_into