Re: improve FOUND in PL/PgSQL
От | Tom Lane |
---|---|
Тема | Re: improve FOUND in PL/PgSQL |
Дата | |
Msg-id | 8966.1029341933@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: improve FOUND in PL/PgSQL (Neil Conway <nconway@klamath.dyndns.org>) |
Ответы |
Re: improve FOUND in PL/PgSQL
|
Список | pgsql-patches |
Neil Conway <nconway@klamath.dyndns.org> writes: > <para> > ! There is a special variable named <literal>FOUND</literal> of > ! type <type>boolean</type>. It will be set to true if: > ! <itemizedlist> > ! <listitem> > ! <para> > ! A SELECT INTO statement is executed, and it returns one or > ! more rows. > ! </para> > ... etc ... This is better than what we had, but still seems confusing: it could easily be read to mean that nothing happens to FOUND if SELECT returns zero rows (ie, FOUND retains its previous value in that case). Perhaps more like: There is a special variable .... It is set by the following types of statement: SELECT INTO sets FOUND to true if at least one row is returned, to false otherwise. ... etc ... Also the initial state of FOUND should be documented (or is that in the other patch?) > Unfortunately, the code is a bit less elegant than I'd like. Indeed. I don't like duplicating the loop condition test, and really the behavior is still wrong: IMHO the FOR statements should not touch FOUND at all before entering the loop. I think you could do this much more cleanly by introducing a local boolean: bool found = false; << remove existing exec_set_found(false) >> << within loop, do found = true at point where existing code does exec_set_found(true) >> << after exiting loop, do exec_set_found(found) >> regards, tom lane
В списке pgsql-patches по дате отправления: