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