Re: help with PL/PgSQL bug
От | Tom Lane |
---|---|
Тема | Re: help with PL/PgSQL bug |
Дата | |
Msg-id | 528.1042251206@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: help with PL/PgSQL bug (Neil Conway <neilc@samurai.com>) |
Список | pgsql-hackers |
Neil Conway <neilc@samurai.com> writes: > On Fri, 2003-01-10 at 20:28, Tom Lane wrote: >> Clearly, RETURN NEXT with an undefined record variable shouldn't dump >> core, but what should it do? Raise an error, or perhaps be a no-op? > I'd vote for making it a no-op. Raising an error is too severe for a > fairly routine occurence, IMHO. If we make it a no-op, it's consistent > with how I understand a SELECT INTO of 0 rows -- it doesn't produce an > "undefined value", but an "empty result set" (like the difference > between "" and a NULL pointer). There's a consistency issue here, though. If the SELECT INTO target is non-record variable(s), the behavior is to set them to NULL. Then if you do RETURN NEXT on that, you'd emit a row full of NULLs. It seems inconsistent that SELECT INTO a record variable produces an undefined result rather than a row of NULLs, when there are no rows in the SELECT result. This would be an easy change to make, I think. We do have a tupledesc available for the SELECT, we're just not using it. Does Oracle's PL/SQL have a concept of record variables? If so, what do they do in this situation? regards, tom lane
В списке pgsql-hackers по дате отправления: