Re: Re: Support plpgsql multi-range in conditional control
| От | Isaac Morland |
|---|---|
| Тема | Re: Re: Support plpgsql multi-range in conditional control |
| Дата | |
| Msg-id | CAMsGm5fVj74eg6rGezsFvGvtTVR+cCb0trcBQoyDfMcRLTu1Lg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Re: Support plpgsql multi-range in conditional control (Pavel Stehule <pavel.stehule@gmail.com>) |
| Список | pgsql-hackers |
On Wed, 25 Jan 2023 at 12:02, Pavel Stehule <pavel.stehule@gmail.com> wrote:
st 25. 1. 2023 v 17:22 odesílatel songjinzhou <2903807914@qq.com> napsal:As follows, we can only repeat the for statement before we use such SQL:beginfor i in 10..20 loopraise notice '%', i; -- Things to doend loop;for i in 100 .. 200 by 10 loopraise notice '%', i; -- Things to doend loop;end;But now we can simplify it as follows:beginfor i in 10..20, 100 .. 200 by 10 loopraise notice '%', i; -- Things to doend loop;end;Although we can only use integer iterative control here, this is just a horizontal expansion of the previous logic. Thank you very much for your reply. I am very grateful!Unfortunately, this is not a real use case - this is not an example from the real world.
And anyway, this is already supported using generate_series() and UNION:
odyssey=> do $$ declare i int; begin for i in select generate_series (10, 20) union all select generate_series (100, 200, 10) do loop raise notice 'i=%', i; end loop; end;$$;
NOTICE: i=10
NOTICE: i=11
NOTICE: i=12
NOTICE: i=13
NOTICE: i=14
NOTICE: i=15
NOTICE: i=16
NOTICE: i=17
NOTICE: i=18
NOTICE: i=19
NOTICE: i=20
NOTICE: i=100
NOTICE: i=110
NOTICE: i=120
NOTICE: i=130
NOTICE: i=140
NOTICE: i=150
NOTICE: i=160
NOTICE: i=170
NOTICE: i=180
NOTICE: i=190
NOTICE: i=200
DO
odyssey=>
NOTICE: i=10
NOTICE: i=11
NOTICE: i=12
NOTICE: i=13
NOTICE: i=14
NOTICE: i=15
NOTICE: i=16
NOTICE: i=17
NOTICE: i=18
NOTICE: i=19
NOTICE: i=20
NOTICE: i=100
NOTICE: i=110
NOTICE: i=120
NOTICE: i=130
NOTICE: i=140
NOTICE: i=150
NOTICE: i=160
NOTICE: i=170
NOTICE: i=180
NOTICE: i=190
NOTICE: i=200
DO
odyssey=>
The existing x..y notation is just syntactic sugar for a presumably common case (although I’m dubious how often one really loops through a range of numbers — surely in a database looping through a query result is overwhelmingly dominant?); I don’t think you’ll find much support around here for adding more syntax possibilities to the loop construct.
В списке pgsql-hackers по дате отправления: