Re: improve FOUND in PL/PgSQL
| От | Neil Conway |
|---|---|
| Тема | Re: improve FOUND in PL/PgSQL |
| Дата | |
| Msg-id | 87it2d82r0.fsf@klamath.dyndns.org обсуждение |
| Ответ на | Re: improve FOUND in PL/PgSQL (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: improve FOUND in PL/PgSQL
Re: improve FOUND in PL/PgSQL |
| Список | pgsql-patches |
Tom Lane <tgl@sss.pgh.pa.us> writes: > 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 [...] Ok, I made this part of the documentation more clear. > Also the initial state of FOUND should be documented (or is that in the > other patch?) Nope, I forgot about that. For the moment, I've documented that the initial state of FOUND is false -- if we want to change that to be NULL (to match Oracle's behavior), it can be done later. > > 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: Ah, ok -- thanks for the suggestion. It required a fair amount of work, since I had to refactor a lot of the logic in the 3 functions that handle PL/PgSQL FOR loops. A revised patch is attached. Cheers, Neil -- Neil Conway <neilconway@rogers.com> PGP Key ID: DB3C29FC
Вложения
В списке pgsql-patches по дате отправления: